Re: Bug in Manual Calls Update? Bug in Concurrency?

Dale E. Reed Jr. ( (no email) )
Sun, 10 May 1998 22:27:26 -0700

Postman Account wrote:
> We have configured "ServerPorts" on our P2-300..
> 128mb RAM machine-- running Access95 w/RadiusNT...
> no sql... about 2% (or so) proc. usage. "Manual
> Calls Update" is selected... running on
> RadiusNT v2.2... with several Ascend MAX 40xx...
> and Cisco.... multiple logins are being denied..
> but, a problem is starting to be noticed.

RadiusNT 2.2 does NOT handle out of order accounting packets
in Manual Calls Update. Therefore, if it receives a stop record
then a start record (both for the same session), it will assume
the user is on-line. I'll add the date check the SQL trigger
does to RadiusNT 2.5's manual calls update to help prevent this.

Make sure the accounting timesouts on the MAX and cisco are
atleast 5-7 seconds. This can cause major issues with
concurrency if not.

There are two possible issues when concurrency is not working.

1. The database was not being updated because if an issue between
the NAS/RadiusNT or RadiusNT/Database. For example, the NAS
was rebooted and the session stops were lost or the NAS did
not send the stop record for the session (some USRs have been
reported to do this when the user just hangs up).

2. The NAS sends accounting data out of order (like a Livinston
will do is accounting gets backed up) and you are using
manual calls update.

-- Dale E. Reed Jr.  (       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |