rlm_sql_log: failure on Accounting-On / Off

Stefan Winter stefan.winter at restena.lu
Mon Aug 13 14:19:08 CEST 2012


I'm still not happy with rlm_sql_log, and this time I'm reasonably sure
it's not just me being dumb.

I've recently received two Accounting-Offs, and got this in the logs:

Mon Aug 13 13:53:18 2012 : Error: [sql-relay-acct-eduroam] Couldn't add
SQL-User-Name attribute
Mon Aug 13 13:53:18 2012 : Error: [sql-relay-acct-eduroam] Couldn't add
SQL-User-Name attribute

Well, sure. Accounting On/Off do not usually have a User-Name attribute
in them as they are global status messages for the NAS.

Looking at the code, this has more than effects than a misleading log

        if (sql_set_user(inst, request, sqlusername, NULL) <0) {
                radlog_request(L_ERR, 0, request,
                               "Couldn't add SQL-User-Name attribute");
                return RLM_MODULE_FAIL;

The module immediately returns FAIL, and will thus not construct nor
save the SQL message (even though the SQL statement itself doesn't
contain SQL-User-Name at all).

The information from the Accounting-On/Off is lost.

That's not nice. Could this code be wrapped around by a test which
determines the packet type, and is more gentle on Accounting-On/Off?


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-devel/attachments/20120813/2fc0b085/attachment.pgp>

More information about the Freeradius-Devel mailing list