Bug/Enhancement request: Race condition with short-term accounting (FreeRadius 2.1.10)

[Arran Cudbard-Bell]

On 28 Aug 2012, at 23:05, Matthias Nagel <matthias.h.nagel at gmail.com> wrote:

> Hello,
> 
> Am Dienstag 28 August 2012, 23:11:57 schrieb Alan DeKok:
>> Matthias Nagel wrote:
>>> if two accounting messages for the same session are sent by the authenticator very quickly, the messages may be processed by the radius server in the wrong order. This results into two sessions being accounted instead of one. The second "phantom" session stays open for ever, because it never receives any update and/or stop message.
>> 
>>  This is a well-known issue with RADIUS.  Packets may appear in any order.
>> 
>>> Example:
>>> 
>>> If a supplicant authenticates and immediately disconnects again, the following steps are executed:
>>> 
>>> 1) The authenticator sends an accounting start message
>>> 2) The authenticator sends an accounting stop message immediately
>>> 3) The RADIUS server receives the start message and assigns it to thread #1
>>> 4) The RADIUS server receives the stop message and assigns it to thread #2
>>> 5) Thread #2 terminates first and the accounting stop message is written to the PostgreSQL database. The SQL UPDATE statement fails, because there is no entry for this session that could be updated, as the start message has not been processed yet. Hence, an INSERT INTO statement is executed as a fail-over measure.
>>> 6) Thread #1 terminates and an SQL INSERT statement is performed in order to log the start message.
>> 
>>  That doesn't make sense.  If the table indexes are set up correctly,
>> the SQL insert will fail at step (6).  The module will then try the
>> update query, which should succeed.
>> 
> 
> This is correct, if one has some kind of key to identify a session that could be used as a database index. But unfortunately there are a lot of authenticators out there, that do not correctly generate radius accounting session ids. Basicly I see three different types (despite the correct one):
> 
> 1) Authenticators that do no send a session id at all (Acct-Session-Id is empty)

Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund, or sue them.

5.13.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

                      #     Attribute
								.
								.
								.
                      1     Acct-Session-Id


> 2) Those that always return the same session id (even if the user name differs)

Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund or sue them.

(see below)

> 3) Those that always return a new session id even if the requests (start/update/stop) belong to the same session

Then they're breaking RFC 2866 and cannot claim to support RADIUS Accounting. Users should log a defect case, demand a refund or sue them.


1.2.  Terminology

   session   Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record with
             its own Acct-Session-Id.

If instead or returning:

HTTP/1.1 200 OK

as the status line a HTTP server started returning

HTTP/6.9 RAINBOWS

It could not claim to implement RFC2616.

By working around compliance issues, you're encouraging your equipment vendors to be lazy, you have to work with them to get them to fix their issues, else it'll be just as crappy for the next person who comes along.

-Arran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120828/54eb5813/attachment-0001.html>