[RadiusNT] Re: RadiusNT Digest

Edsonet ( administrator@yellowhead.com )
Tue, 03 Aug 1999 08:33:00 -0600

We have encountered a similar problem, but very infrequently. The problem
is always associated with a poor quality line, or a poor quality modem on
the customer's end (mostly rural customers). The customer dials in and the
modems negotiate a poor quality connection. Before RadiusNT has a chance to
record the login, the modems disconnect but Radius never records the
disconnect. The customer must then wait for someone else to use that
particular line before he/she can login again.

On the odd occassion, the customer end will disconnect but the NAS end will
not. This happens with automated dialers that don't allow sufficient delay
time before redialing. The customer has a brief period in which he/she can
catch the modem in the middle of its reset operation. When this happens,
the customer cannot dial in again until the idle timeout kicks in. We find
a 1 second delay time on automated dialers will prevent this from occurring.

J.A. Coutts
Systems Engineer
***************** REPLY SEPARATER ******************
At 12:00 AM 08/03/1999 -0700, you wrote:
>Subject: [RadiusNT] Failure to clear serverports
>From: "ValNet Sysop" <sysop@dswebnet.com>
>Date: Mon, 2 Aug 1999 12:58:43 -0700
>Can't find this in the archives.
>We are running RadiusNT 2.5.162 with concurrency control, variable login
>limits, manual calls update and Not stop records only using an Access 97
>The problem is a failure to get the ServerPorts table updated on a failed
>login. The user's modem gets far enough that a start record is inserted into
>the Calls table and then the modems decide the line is too noisy and
>disconnect. Radius gets a stop record into the Calls table for the session
>but fails to update the AcctStatusType to 2 in the ServerPorts table. The
>user is now over his login limit and can not log on until someone happens to
>hit that port.
>The short term (I hope) work around is to set them up with two possible
>I can't seem to make it happen to watch the process in debug so this is all
>I have to work with.
>Any ideas on why the update is failing to happen would be appreciated.
>Gerry Barnes

For more information about this list (including removal) go to: