Question about Logging

[Alan DeKok]

Aaron Spanik wrote:
> Recently, however, there has been reason to suspect that the two remote
> RADIUS servers are behaving inconsistently with each other (i.e. auth
> fails on one and then immediately succeeds on the other).
> Unfortunately, I have zero access to the remote RADIUS servers and
> limited access to the folks who could tell me whether something is, in
> fact, wrong with the remote configuration.

  I suggest getting access.  Sorry... but it's the simplest way to debug
things when something is going wrong.

> In order to provide statistics on my end or at least look for trends, I
> would like to keep track of what remote server a given request is
> proxied to, but I can't seem to find an easy way of doing it:

  See the pre-proxy section.  The destination IP address is determined
before that section is run.

> - I have auth_logging turned on so that my radius.log file contains
>   basic Yay/Nay information about a particular auth request, but the IP
>   of the server the request was proxied to is not included.

  The default log messages don't include IP addresses of the proxies.

> I have also peeled through all the dictionary files looking for an
> appropriate RADIUS Attribute which I could use.  I found
> Packet-Src-Ip-Address and Packet-Dst-Ip-Address, which didn't work in
> any of the detail sections, as they all returned 127.0.0.1, which makes
> some sense to me given the initial source and destination of the
> request packets; I'm also pretty sure I shouldn't be using parameters
> from dictionary.freeradius.internal this way.

  That's what they're defined for.

  See also "man unlang".  If you want the destination IP address of the
*proxied* packet, you need to use %{proxy-request:Packet-Dst-IP-address}

> So my question is this:  short of editing the source to make the
> auth_log pop the home server being contacted into the loglines in
> radius.log, is there any way to get that information on a per-request
> basis?  Is there some unlang magic I could work in the pre- or
> post-processing phases?  It doesn't really matter to me where the
> information goes, as long as I can associate it with a particular
> request.

  It's already associated with the request.  You've just got to put 2&2
together to refer to the *proxied* packet, not the *request* packet.

  I'd also suggest upgrading to recent code (git.freeradius.org).  It
has *very* good statistics tracking available via RADIUS packets.  You
can get accept/reject per home server.  See raddb/sites-available/status.

  You can also log much more configurable messages via the "linelog"
module.  See raddb/modules/linelog.

  Alan DeKok.