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
Edsonet/TravPro
***************** 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
>database.
>
>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
>logins.
>
>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
>sysop@dswebnet.com
For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart