Re: (ASCEND) Ticket #802135 - Disconnect Problems on 4048 with 7.0.1

["R. P. McCormick" <RPM@GCQ.net>]

Seeing a number of different responses on this one,
I'll also add our interpretation:

>> 11   -  DCD detected, but went inactive

A call was received - and was assigned to a modem
in the Max.  The connection was terminated because
the Max's modem lost Data Carrier Detect ... which
indicates the remote modem and Max's modem 
could not (or no longer) communicate.  I belive most
of the time we see this during initial modem handshaking,
and not for sessions that have been established or
running for some time.  Check your radius logs 
(STOP events) for more details on when this happens;
try to corelate to user feedback or your own experience.



>> 45  -   PPP LCP got terminate request from far end


If the remote client is setup properly this is what you should see.
For example, in Windows 9X, if you right click on the modem 
icon in dial-up networking that's next to the clock on the task bar,
and choose disconnect, the Windows DUN will send the
terminate request to the Max, and the session will cleanly
be shut down.


>> 100 -   Session timeout

A user's session has been terminated by the Max
due to inactivity.  We also consider these both normal
and acceptable ... as if an idle timer determins that a
link has been up without traffic we let the Max timeout
(i.e., disconnect) the session.


>> 185  -  Remote End hung up - signal lost form far end

Exactly what it says ... for reasons the Max does not know,
the connection with the remote modem was lost.

Indeed you can cause this fairly easily:  just establish
a connection and then disconnect the remote modem
from the telephone line.

>From our research, we feel the 185 disconnect can
be attributed from the following:

- phone line quality degradation

We've experimented with a number of "bad" telephone
lines - including some that would not even establish a
v.90 session.  Using some USR modems that keep
track of statistics we looked at the stats after an
abnormal disconnect ... often finding a lot of modem
retrains, and typically disconnects from the modem
due to its inability to successfully retrain.  In other words,
when a modem finds the line quality degrades beyond
a certain threshold, it attempts to "retrain" (almost like
the initial connection effort).  This retrain can be seen
as a period of inactivity - sometimes between 30 and
60 seconds.  Sometimes the modem can continue
where it left off, and other times it can't, in which case
it disconnects (hangs up).  Max gets 185 disconnect.

- human problem

User disconnects modem from phone line, disconnects
power from external modem (effectively hanging up modem!),
engages (picks up) a telephone that is also on the same
line as the modem whilst it is connected, phone company
technician "taping" or working on wires, etc.

- implementation problems

A good implementation of the PPP protocol will send
a disconnect to the Max and then take down the connection.
But a poor implemenation may work as follows:
 - queue up the disconnect message
 - before the message is successfully sent,
   cause the modem to be disconnected
   usually via negotiation of the modem control signals
   (like DTR, etc.)


I'm sure there's other reasons for the 185's,
but as you can see - there's really no way that the Max
can know or tell you which one it may be, or why.
You can only ascertain that by careful analysis
of the radius logs ... and possibly radius server
status messages (like the Ascend Access Control's)
based on detailed (and accurate) feedback from
the remote user.

Hope this helps.
Bob McCormick


++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>