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

Scott Lagos ( slagos@net1plus.com )
Mon, 11 May 1998 08:07:42 -0400

Will disabling Manual Calls update on a MS Access DB help this situation or
make it worse?

At 10:27 PM 5/10/98 -0700, you wrote:
>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. (daler@iea-software.com)
>_________________________________________________________________
> IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs
> Internet Solutions for Today | http://www.iea-software.com
>
> ----------------------------------------------------------
> RadiusNT Mailing List lists@iea-software.com
>