Re: RADIUS accounting bug

Victor Muslin (vmuslin@prodigy.com)
Tue, 19 Mar 1996 00:54:45 -0500 (EST)

We have rarely seen this happen with Livingston, though we have plenty
of other NASes that misbehave. This is what I did:

I keep a list of active sessions in a "sessions" table. If a start
arrives with the same user IP or nas_id/port combination as the
existing session, then I copy the existing session to a "collision"
table and replace it with the new session in the "sessions"
table.

Every stop is checked against the sessions table first and then, if a
match is not found (based on the combination of
nas_id/port/username/user_ip/session_id), it is checked against the
collisions table.

Also, every time there is a collision, in addition to shifting a
session to the collision we prune the collision table by expiring all
sessions over 24 hours old. This scheme seem allows for reasonable out
of order packets scenario (such as start packet for the next session
arriving slightly before the stop for the previous session) with the
same user_ip or nas_id/port...

Hope this helps.

\\\|///
\\ - - //
( @ @ )
+------------------------------oOOo-(_)-oOOo--------------------+
| Victor Muslin | |
| Prodigy Services Company | Voice: (914) 448-4737 |
| 445 Hamilton Avenue, H11A | Fax: (914) 448-8462 |
| White Plains, NY 10601 | Internet: vmuslin@prodigy.com |
+-----------------------------+--------Oooo---------------------+
oooO ( )
( ) ) /
\ ( (_/
\_)

On Mon, 18 Mar 1996, Leo Savage wrote:

> I wish to report an apparent bug in the Livingston Portmaster RADIUS support.
>
> This came to our attention regarding the ESVAnet radiusd support of
> session limiting, as per the suggestion from Carl Rigney on how it could
> be done.
>
> The general idea is for radiusd to keep a table of which users are on
> which ports, adding an entry when an accounting "start" record is
> received and rmoving it when an accounting "stop" record is received.
>
> It now appears that it is possible to receive a "start" record and then
> never receive a corresponding "stop" record. Instead, we receive a new
> "start" record when the port is reused. This becomes more apparent now
> that we have switched our lines to round-robin hunting.
>
> I would regard this as a bug. ComOS should never send an accounting
> "start" record without later sending a corresponding "stop" record when
> and if the session terminates for any reason.
>
> Comments? Am I off base here?
>
> --
> ("`-/")_.-'"``-._ Leo Savage
> . . `; -._ )-;-,_`)
> (v_,)' _ )`-.\ ``-' leo@esva.net
> _.- _..-_/ / ((.'
> ((,.-' ((,/ http://www.esva.net/~leo/
>
>