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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html