Processing Packets

Every line for a packet starts with a request number in parentheses, for example, (0). The number lets you match up all the messages for one packet when the output contains messages from multiple packets which are interleaved due to threading.

The first message for a new packet comes from the network listener proto_radius_udp, and does not yet have a request number:

All further processing for the request happens inside a virtual server, which shows the virtuakl server name on the next line, in this case default {. The following messages shows the packet type, the RADIUS ID, the source and destination address and port, and the network interface.

After the Received message, the server prints the attributes which it received in the packet. For RADIUS, there are also some attributes added by the server which describe the packet. A Net attribute which contains the IP addresses and ports (source and destination) socket details, and a Packet attribute which contains the RADIUS header information. Finally, the Packet-Type attribute gives the packet type.

In v4, we now call the first processing section recv Access-Request. In version 3 this section was called authorize. Its job is the same: look up the user in a database, determine what type of authentication to use, and set up the Auth-Type control attribute that tells the server which authenticate section to run next.

The Running line names the section which is being run, and the file where the section was loaded from. If you suspect that the server isn’t using the configuration you’re editing, you can use this information to double-check where the server is loading its policies from.

Each module in the section runs in order. Messages which come from a module are prefixed with the module’s name and ` - `. After the module returns, the server prints the module name and its return code in parentheses.

See the module rcode page for the meaning and behavior of the various return codes such as ok or updated.

In this output, the files module finds the user bob in the users file and sets control.Password.Cleartext from the entry there, returning ok. The pap module then sees a known-good password is available, sets control.Auth-Type = pap, and returns updated.

The section closes with } # recv Access-Request updated, so the final return code of the section is updated.

When you are diagnosing a problem, read this section carefully to answer:

After the recv Access-Request section, the server checks whether Auth-Type was set. If it was not set, the server rejects the request immediately:

In this trace, Auth-Type = pap was set, so the server runs the authenticate pap section.

The pap module compares the User-Password from the packet against the known-good password that was set earlier by the files module.

For a wrong password, you should see output similar to this:

For a correct password, you should see output similar to this:

When the server sends a reply, it runs a send section which is named after the packet type.

Accounting packets follow a similar pattern, but use recv and send section names taken from the accounting packet names.. The recv Accounting-Request section runs when the server receives an Accounting-Request packet. After that section runs, the server looks at Acct-Status-Type, and runs an accounting section named for that status type. For example, accounting Start { }. This behavior lets you configure policies which are run only when specific types of accounting messages are received.

For example, you likely want to run different policies on "Start" packets, than "Stop" packets.

Finally, the send Accounting-Response section runs before the reply is sent.

If Ready to process requests was printed but nothing appears after that, the server is not receiving any packets. That is a network or firewall problem, not a server configuration problem. Check that the NAS is sending packets to the correct IP address and port, and that no firewall is blocking UDP on port 1812 or 1813.