sql returns fail for some stop requests

Arran Cudbard-Bell a.cudbardb at freeradius.org
Thu Jul 19 11:37:54 CEST 2012

> This seems to be the case for duplicated connections, there are several accounting start requests sent within a few seconds from each other, all of them create a new accounting record, and no stop request is sent for these sessions.

I don't know about your original issue, but there's a bug in the default schema for released versions of 2.1.x.

The acctuniqueid column should have a UNIQUE KEY constraint on it, but in the default schema it doesn't.

mysql -e 'DROP INDEX acctuniqueid ON radacct; CREATE UNIQUE INDEX acctuniqueid ON radacct (acctuniqueid);' radius

Will fix your duplicates issue.

All users of rlm_sql_mysql with a schema based on 3.0 versions prior to 87a8919aa23678f35778beae4ca6f5decfe3bab6, and 1/2.x before 3651b564b98a7511e4a0793e86fbc91dcb650d07 should add the unique key constraint to avoid the possibility of duplicate sessions from multiple accounting starts. Its been this way for at least five years, but it's definitely incorrect.

The alternate query should be executed when the server errors out after hitting a unique value constraint on the accuniqueid, at which point it'll try and update the existing record with new data. If no such constraint exists it will just insert a new row, and you'll get the duplicate sessions.


More information about the Freeradius-Users mailing list