#  -*- text -*-
######################################################################
#
#	This virtual server gives an example of reading the detail
#	file for the v4 configuration.
#
#	$Id: 60f5efc7f7ffdbd560eff0096c73b71e2324c7ee $
#
######################################################################
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

	#
	#  The "listen" section MUST have a second name here, which
	#  says "load the detail file processor, and not the typical
	#  RADIUS UDP / TCP socket IO.
	#
	listen detail {
		#
		#  Overrides the default transport prefix set by
		#  namespace and loads the detail reader code.
		#
		proto = detail

		#
		#  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
	}

	#
	#  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"
