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.
This virtual server will read detail files from the following directory.
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.
Overrides the default transport prefix set by namespace and loads the detail reader code.
Types of packets we are reading.
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"
Check for the existence of detail files.
You MUST also configure a "work" subsection below.
The wildcard to use for finding detail files
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
Configuration related to processing the "detail.work" file.
This MUST also be specified, along with the "file" subsection above.
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.
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.
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.
Whether or not the detail.work file reader retransmits packets which have failed.
default = yes
Limits for the files, retransmissions, etc.
Number of simultaneous packets it will read from the file and feed into the server core.
Useful values: 1..256
Initial retransmit time: 1..60
If there is no response within this time, the module will retransmit the packet.
Maximum Retransmit Time: 5..30
The maximum time between retransmissions.
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".
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".
The detail file reader runs the normal RADIUS / DHCP / etc. processing sections.
We handled the packet successfully. Run the "send ok" section.
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.
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.
Default Configuration
# This virtual server gives an example of reading the detail
# file for the v4 configuration.
server detail {
namespace = radius
directory = ${radacctdir}/detail
listen detail {
proto = detail
type = Accounting-Request
# priority = 1
file {
filename = "${...directory}/detail-*"
poll_interval = 5
}
work {
filename = "${...directory}/detail.work"
track = yes
max_entry_size = 65536
retransmit = yes
limit {
max_outstanding = 1
initial_rtx_time = 1
max_rtx_time = 30
max_rtx_count = 6
max_rtx_duration = 40
}
}
}
recv Accounting-Request {
if (!&Event-Timestamp) {
&Event-Timestamp := &Packet-Original-Timestamp
}
if (&Event-Timestamp < %c) {
&request.Acct-Delay-Time += %c - &Event-Timestamp
}
ok
}
send Accounting-Response {
ok
}
send Do-Not-Respond {
ok
}
} # virtual server "detail"