Subject: Re: (usr-tc)Disconnect User Problem

From: Mark Thornton <[email-masked]>
Date: Wed, 22 Dec 1999 18:00:30 +0000

The danger is if there is any problem in the reporting of accounting packets
to the radius server, or if the radius server is offline for a few minutes,
the logoffs may be missed. In that case the radius would deny access even
though the client had dropped offline.

The later versions of the software we use had several features to combat
this. First, if another user logged in using the same port as on open
session the system closed it because it obviously was disconnected. Second,
we lengthened out the retry interval on accounting packets as well as the
number of retries. Theoretically our radius could be down for 20+ minutes
and still receive the accounting packets and resynchronize when it started
back up. Of course if your radius is down for 20+ minutes...

Mark Thornton
San Marcos Internet, Inc.
512-393-5300

-----Original Message-----
From: Mark E. Levy <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 22, 1999 9:27 AM
Subject: Re: (usr-tc)Disconnect User Problem

>Im what way?  Our radius server does this very nicely.  It simply keeps
>a running list of all logged-in users.  When a login is attempted, it
>checks the list to see if there is already an entry for that username.
>If there is, and that user is not permitted multiple logins, an
>access-reject is returned to the ARC.  Works great and has never made a
>mistake.
>
>Jeff Mcadams wrote:
>
>> But then I think about the RADIUS server trying to keep track of the
>> state on all the Arc's think of that as being very error prone.  :)
>
>--
>---------------------------------------------------------------------
>Mark E. Levy, President
>FSINet, Inc.
>800-827-6085 x202
>847-753-6832 fax
>www.fsi.net
>[email-masked]
>---------------------------------------------------------------------
>
>-
> To unsubscribe to usr-tc, send an email to "[email-masked]"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address.  Do not use quotes in your message.

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: "Mark E. Levy" <[email-masked]>
Date: Wed, 22 Dec 1999 19:04:40 +0000

Ours deals with that as well.  When Radius starts up, it clears the user
list.  IMHO, I'd rather have a user get away with multiple logins for a
short time, than have them blocked from logging on at all.  We've never
had a missed accounting stop message cause the running list to be
innaccurate.

Part of the reason for our confidence is they way our Radius server(s)
are configured.  We're using OpenVMS in a dual-node SCSI cluster.  For
those of you who are unfamiliar with OpenVMS' clustering abilities, it's
what Unix and WNT clusters want to be when they grow up.  We run Radius
on both nodes using shared databases.  Our NAS is configured to send
access requests to both nodes in a round-robin fashion, and accounting
messages to both always.  If one node happens to miss the accounting
message, chances are that the other won't miss it also.  At least, it's
never happened.  For more info on our Radius, see www.radiusvms.com.

-