On Sat, 23 Aug 2008 07:04:11 +0200 Alan DeKok <aland@deployingradius.com> wrote:
Aaron Spanik wrote:
*snip*
I suggest getting access. Sorry... but it's the simplest way to debug things when something is going wrong.
Always. But sometimes one is forced to prove something is wrong before the other end will consent to looking for the problem.
*snip*
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}
See, I read "man unlang" and noticed the %{<list>:<attribute>} syntax, but then failed to remember reading that when I actually went about trying to use %{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'm glad that I appeared to have half a clue and lacked only the other half to rub it against ;) As you no doubt know, once I used %{proxy-request:Packet-Dst-Ip-Address} I started seeing exactly what I wanted to see in my logs.
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.
That sounds excellent; I will check out the GIT version. Can you comment on how long it is likely to take before those features make it into an official release?
You can also log much more configurable messages via the "linelog" module. See raddb/modules/linelog.
Alan DeKok.
Thanks much for your response; it was truly helpful. /a -- Aaron Spanik a.spanik@ns.sympatico.ca