> 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?
We run USRobotics terminal servers with as I know netserver card software
almost "from Livingston". I do not want to say that it's somebody else
but not USRobotics' responsibity to have robust system, but we experiance
the same problem -- accounting radius process would receive start packet
and no stop packets.
Regards,
K
-------------------------------------------------------------------------
Konstantin Beznosov School of Computer Science
Florida International University
Beznosov@FIU.Edu
http://www.cs.fiu.edu/~beznosov