#  -*- text -*-
######################################################################
#
#	This virtual server gives an example of reading the detail
#	file for the v4 configuration.
#
#	$Id: 9f0a89788f5ca162cfd997f00e6bf88ea79bd740 $
#
######################################################################
server detail {
	#
	#  In v4, all "server" sections MUST start with a "namespace"
	#  parameter. This tells the server which protocol is being used.
	#
	#  RADIUS, or DHCPv4, or any other protocol supported by the server.
	#
	namespace = radius

	#
	#  This virtual server will read detail files from the following
	#  directory.
	#
	directory = ${radacctdir}/detail

	#
	#  This is the detail file listener.
	#
	listen detail {
		#
		#  A special-case over-ride for detail files. We are in the RADIUS
		#  namespace, but we load a special "detail" handler, instead of the
		#  generic RADIUS udp / tcp transports.
		#
		#  This configuration also enables "transport = file", which is not
		#  normally allowed for RADIUS.
		#
		handler = detail

		#
		#  We read from files
		#
		transport = file

		#
		#  Types of packets we are reading.
		#
		type = Accounting-Request

		#
		#  There is no need to specify a transport. The default is `file`,
		#  which is the only one supported.
		#

		#
		#  Unlike v3, there is no "load_factor" configuration.
		#
		#  Instead, the detail file listener is "self clocking". The
		#  listener reads one entry, and as soon as it gets a response to
		#  that entry, the listener reads a second entry.
		#
		#  Packets from the detail listener are low priority, so they are
		#  processed only when there is nothing else to do. i.e. if the
		#  server receives many Access-Request or Accounting-Request packets
		#  from the network, they will be processed *before* any packets
		#  from the detail file.
		#
		#  This behavior ensures that the detail file is read as fast as
		#  possible. At the same time, it ensures that the detail file does
		#  not affect higher priority packets from the network.
		#

		#
		#  Set the priority for packets from the detail listener. For
		#  safety, it should be set low. This means that "real" packets from
		#  a NAS will be processed before packets from the detail listener.
		#
		#  i.e. the packets from the detail listener won't be processed
		#  until ALL OTHER packets in the system have been received,
		#  processed, and responded to.
		#
		#  The default is for the server to process packets in the following
		#  priority:
		#
		#	Status-Server
		#	Access-Request
		#	Disconnect-Request
		#	CoA-Request
		#	Accounting-Request
		#	packets from the "detail" listener.
		#
		#  This priority setting ensures that the server will be responsive
		#  and stable.
		#
		#  Allowed values: 1 to 65536.
		#
		#  Setting it to "1" means "very low priority".
		#
		#  Setting it to "65536" means "higher priority than Access-Request
		#  packet"
		#
#		priority = 1

		#
		#  Check for the existence of detail files.
		#
		#  You MUST also configure a "work" subsection below.
		#
		file {
			#
			#  The wildcard to use for finding detail files
			#
			filename = "${...directory}/detail-*"

			#
			#  If there are no detail files in the directory, the listener will
			#  periodically wake up to check for new entries.
			#
			#  If this is set to `0`. then the server will rely on file system
			#  notifications to discover when a detail file has been added.
			#  Setting it to `0` only works on Linux. On other operating
			#  systems, it MUST be set to a non-zero value.
			#
			#  Allowed values: 0 to 3600
			poll_interval = 5
		}

		#
		#  Configuration related to processing the "detail.work" file.
		#
		#  This MUST also be specified, along with the "file" subsection
		#  above.
		#
		work {
			#
			#  The name of the current working file. If omitted, it is the
			#  directory from the `file` subsection, `filename` argument given
			#  above, with "/detail.work" appended to it.
			#
			#  As of v4, you can have multiple detail file readers in the same
			#  directory. The only caveat is that the wildcards CANNOT overlap.
			#
			#  The best way to enforce that is to give the the files different
			#  prefixes.
			#
			filename = "${...directory}/detail.work"

			#
			#  Track progress through the detail file. When the detail file is
			#  large, and the server is restarted, it will read from the START
			#  of the file.
			#
			#  Setting `track = yes` means it will skip packets which have
			#  already been processed. The default is `no`.
			#
			track = yes

			#
			#  The maximum size (in bytes) of one entry in the detail file. If
			#  this setting is too low, then the "too large" entries in the
			#  detail file will be ignored.
			#
			max_entry_size = 65536

			#
			#  Whether or not the detail.work file reader retransmits packets
			#  which have failed.
			#
			#  If this configuration item is set to `no`, then the reader will
			#  ignore any failures, and will go to the next entry as soon as
			#  the current entry is finished, even if it failed to process that
			#  entry.
			#
			#  default = yes
			#
			retransmit = yes

			#
			#  Limits for the files, retransmissions, etc.
			#
			limit {
				#
				#  Number of simultaneous packets it will read from the file and feed into
				#  the server core.
				#
				#  Useful values: 1..256
				max_outstanding = 1

				#
				#  Initial retransmit time: 1..60
				#
				#  If there is no response within this time, the module will retransmit
				#  the packet.
				#
				initial_rtx_time = 1

				#
				#  Maximum Retransmit Time: 5..30
				#
				#  The maximum time between retransmissions.
				#
				max_rtx_time = 30

				#
				#  The following are maximums that *all* apply. i.e. if any one of the
				#  limits is hit, the retransmission stops.
				#

				#
				#  Maximum Retransmit Count: 0..20
				#
				#  How many times the module will send the packet before giving up.
				#
				#  A special value of "0" means "retransmit forever".
				#
				max_rtx_count = 6

				#
				#  Maximum Retransmit Duration: 0..600
				#
				#  The total length of time the module will try to retransmit the packet
				#
				#  A special value of "0" means "retransmit forever".
				#
				max_rtx_duration = 40
			}
		}
	}

#
#  The detail file reader runs the normal RADIUS / DHCP / etc.
#  processing sections.
#
recv Accounting-Request {
	#
	#  If there's an Acct-Delay-Time, increase its value based on the
	#  difference between when the packet was written, and the current
	#  time.
	#
	#  Note that we do NOT rely on any Event-Timestamp in the original
	#  packet, it could be wrong.
	#
	if (Acct-Delay-Time) {
		Acct-Delay-Time += %l - Packet-Original-Timestamp
	}

	if (!Event-Timestamp) {
		Event-Timestamp := Packet-Original-Timestamp - %{Acct-Delay-Time || 0}
	}

	#
	#  We handled the packet successfully. Run the "send ok" section.
	#
	ok

	#
	#  If the "recv" section returns "ok" or "updated", it will run the
	#  "send ok" section to send the reply.
	#
	#  All other return codes (e.g. "fail") will cause it to run the
	#  "send fail" section.
	#
}

#
#  If the listener is configured with 'track = yes', then the entry in
#  the detail file is marked up as being "done". Subsequent re-reads
#  of the same detail file (e.g. on server restart) will skip the
#  "done" entries.
#
send Accounting-Response {
	ok
}

#
#  All failed packets sent by the detail listener should be processed
#  through the 'send Do-Not-Respond' section.
#
#  If the listener is configured with 'track = yes', then the packet
#  will be retransmitted by the detail file reader, until the packet
#  returns "success". See the "limit" subsection above for
#  retransmission configuration.
#
send Do-Not-Respond {
	ok
}
} # virtual server "detail"
