Re: stranded?

Michael Whisenant ( mwhisen@airnet.net )
Sun, 10 May 1998 12:18:31 -0500

This is the same process that I am referring to in my concurrency
revisited thread. The session appears to be active, yet the user is not
online. I run all my RADIUS processes in x-15 debug mode, and I have not
seen anything that would indicate a bad STOP record, and since it happens
so infrequently (10 out of 30,000) calls or so, it would be like finding a
needle in a haystack. I have been trying to log in another database the
performance monitor reasons the USR shows as call termination reason and
see if I can find a code that has the spproximate same number of reasons.

>> I occassionally get "stranded" sessions for no apparent reason other than
>> perhaps an unusual disconnection from the user's modem. This leaves Emerald
>> thinking that they're still online and of course, they can't get back on.

>> 1) What causes this, and is there any way of correcting it? (we're using
>> USR Total Control racks)
>
>Typically the people who report this are running USR gear and its
>when people disconnect either by just dropping the line or some
>other non PPP disconnect. I would guess its a bug in the USR gear
>that causes something funny to happen to the accounting stop record
>for that session. Maybe someone with a USR could run RadiusNT in
>-x15 debug mode and capture the debug of the session hanging up?
Since this happens infrequent. Tell me how, and I will capture the
information. It is happening about 10 times or less per day. I am now
manually processing a script that takes the information in the calls table
by NAS, telnets into the NAS, and confirms the user is still active. If
there is a difference it will reset the port in the telnet session twice.
It finds less than 10 per day in my environment of about 30,000 calls.

>
>> 2) Does this ever clear by itself? I CAN go into the "online" display,
>> highlight the offender and clear it, but I was wondering if it will ever
>> "heal".
>
>The next time someone logs onto the port it will clear.
If you change the hunt sequence from least used and round robin in the
terminal server to straight line, and fixed assignment you should never see
this problem. In one POP that is the only way that I could get the lines
provisioned, and I have never had a problem there. Reason the port the
user is disconnected from is immediately reassigned another user on the
next call. The natural disadvantage is that if/when you have a problem
such as a modem gets hung, the entire hunt group is held up with that one
call. It is much easier to find a problem and correct it this way, vs a
single modem in a 500 group pool having a problem, then once every several
hundred calls you have a problem.

>
>--
>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
>
> ----------------------------------------------------------
> Emerald Mailing List listserver@emerald.iea.com
>
Michael J. Whisenant
Vice-President, Operations
AIRnet Internet Services, Inc.
ph: (256) 704-4692 fax: (256) 704-2329