On Wed, 2013-06-05 at 09:15 -0400, Alan DeKok wrote:
Stelian Ionescu wrote:
Take for instance the expansion of '%{Nas-Ip-Address}'::inet from that trace: it's '=3F.=3F.=3F.=3F'::inet which looks like an url-encoding of "?.?.?.?". I can't imagine how this can be since the debug output from rlm_perl, which prints all VPs in the request, shows that the actual value is correct so my only guess is that the xlat function is somehow buggy.
Ah. Let me guess... you're running the query from the inner-tunnel, and you didn't set "copy_request_to_tunnel = yes".
The "?.?.?.?" output is produced when the NAS-IP-Address attribute doesn't exist. Since you say it exists, the only place it normally doesn't exist is in the inner-tunnel.
It's true that copy_request_to_tunnel wasn't set to "yes", but the problem still remains in that radius_axlat() didn't output a literal '?' but its hex-encoding, and that's caused by the way sql escaping is currently done. Give these request VPs: Event-Timestamp = 'Jun 7 2013 18:02:09 CEST' SQL-User-Name = 'test' then the SQL fragment «COALESCE(NULLIF('%{Event-Timestamp}', ''), '%S')::timestamp with time zone,'%{SQL-User-Name}'» gets translated into «COALESCE(NULLIF('Jun 7 2013 18:02:09 CEST=27=2C =27=27=29=2C =271970-01-01 01:00:00=27=29::timestamp with time zone=2C=27test'» Notice how the apostrophes and commas are getting hex-encoded, thereby making the resulting query invalid. Another strange thing in that expansion is that %S now gets consistently expanded to «1970-01-01 01:00:00» -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib