Anyone else haveing this problem, any ideas ?
Thanks
Edward B
ebroo@mychoice.net
>
> 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
>
> ----------------------------------------------------------
> Emerald Mailing List listserver@emerald.iea.com
>