SQL results going ... wrong

[Stefan Winter]

Hi,

I'm just implementing a new virtual server with a slightly complex query
and sizable result set coming back in radreply. The query goes out as
expected, and the MySQL reply is well-formed and looks as expected in
wireshark when it comes back. But the debug output is ... interesting:

Thu Apr 14 15:43:07 2011 : Info: [sql-aai] User found in radcheck table
Thu Apr 14 15:43:07 2011 : Info: [sql-aai] expand: SELECT * FROM
reply_aai_firstname WHERE username='%{SQL-User-Name}' UNION ALL SELECT *
FROM reply_aai_lastname WHERE username='%{SQL-User-Name}' UNION ALL
SELECT * FROM reply_aai_mail WHERE username='%{SQL-User-Name}' UNION ALL
SELECT * FROM reply_aai_eduPersonAffiliation WHERE
username='%{SQL-User-Name}' -> SELECT * FROM reply_aai_firstname WHERE
username='swinter' UNION ALL SELECT * FROM reply_aai_lastname WHERE
username='swinter' UNION ALL SELECT * FROM reply_aai_mail WHERE
username='swinter' UNION ALL SELECT * FROM
reply_aai_eduPersonAffiliation WHERE username='swinter'
Thu Apr 14 15:43:07 2011 : Error: rlm_sql: Invalid operator
"?x�{?(�{?@�{?D�{?<�{?D�{?Z�{?]�{?v�{?swinter" for attribute +=
Thu Apr 14 15:43:07 2011 : Error: rlm_sql (sql-aai): Error getting data
from database
Thu Apr 14 15:43:07 2011 : Error: [sql-aai] SQL query error; rejecting user

Something looks like accessing memory where it better shouldn't.

If I execute the xlated query on the MySQL server directly, the result
looks beautiful:

+----------+-----------------------+----+----------------------------------------------------------------+
| username | attribute | op | value |
+----------+-----------------------+----+----------------------------------------------------------------+
| swinter | RESTENA-AAI-Attribute | += | urn:oid:2.5.4.42='Stefan' |
| swinter | RESTENA-AAI-Attribute | += | urn:oid:2.5.4.4='Winter' |
| swinter | RESTENA-AAI-Attribute | += |
urn:oid:0.9.2342.19200300.100.1.3='stefan.winter at education.lu' |
| swinter | RESTENA-AAI-Attribute | += |
urn:oid:1.3.6.1.4.1.5923.1.1.1.1='member' |
+----------+-----------------------+----+----------------------------------------------------------------+

So it must go wrong somewhere in the server.

That same server executes many many other SQL queries of the radcheck
style without issues. This is the first time I'm using a radreply query
though. Version is 2.1.10. mysql client lib is so old I'm too ashamed to
tell here.

So... any known badnesses in MySQL/radreply? Anything I should do
(besides updating mysql client libs, which has right now popped near the
top of my TODO list)?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20110414/c15fe05d/attachment.pgp>