Stelian Ionescu wrote:
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.
The escaping is controlled by the "safe-characters" configuration in SQL. If you want to allow '?', edit that configuration item.
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.
Because that's how the SQL escaping function works. See? If you run the same xlat in a non-SQL context, you'll see '?' instead of the hex encoded version.
Another strange thing in that expansion is that %S now gets consistently expanded to «1970-01-01 01:00:00»
That shouldn't be happening. It's taken from the packet timestamp, which always gets initialized to the current time. Alan DeKok.