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

["Steven T. Pierce" <stp@Dynasty.Net>]

Is there anyway to assure no 100 - Session timeouts ? caused by the Max
?

I have everything I know currently set to 3600 (60 minutes) but after
some experiments, noticed after connecting to the 4048 running 7.0.1
with my 3Com Impact IQ modem (and not launching any programs) that I was
disconnected with a cause code 100 after 15 minutes ( 900 seconds) but I
find that no where in my max settings.

A normal connect and disconnect (cause 45) (as reported by a SQL 6.5
query)

(ascendxmit rate 64000, ascenddatarate 64000)

acctstaustype    ascendconnectprogress    ascenddisconnectcause
1                        (null)                                (null)
1                        (null)                                (null)
2                        60                                    45
2                        60                                    45

A cause 100 disconnect  (which I wish to stop for the time being)

acctstaustype    ascendconnectprogress    ascenddisconnectcause
1                        (null)                                (null)
1                        (null)                                (null)
2                        60                                    100
2                        60                                    100

I would like to set the max up (for testing purposes) so that every user
authenticated by Radius (NT) does not get idle timed out based on our
equipment settings... so that someone can connect to us and do nothing
and be connected for days.... after this is working, will reimplement
some type of more logical idle timeout period.

If anyone has this type of config on a 4048 that would like to share
settings (idle , TS idle mode, ts idle , etc... ) please respond.  I am
still waiting on Ascend's Tech Support team response to this issue.

Steven T. Pierce
stp@dynasty.net
Dynasty Online, Inc.

"R. P. McCormick" wrote:

> 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>

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