Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Authentication times
Hi,
> I don't know if this has been hit on yet, but since we've installed the
> Max4048 here, we're finding that authentication times on Windows 95 dialups
> are horrendously long. I did notice that the authentication itself is
> quick (2 secs max) but Windows 95 doesn't seem to recognize this and can
> take up to a minute to report back.
>
> Has anyone else found this problem and fixed it?
>
First the fix I found, is to switch off software compression in the DUN and all
protocols other than TCP/IP.
I investigated the problem back to repeated tries of the DUN to establish a
compressed connection via CCP - I think it tries to do MS-Stac.....
These tries time out a few times, then the DUN gives up.
The MAX sends no protocol-NAK or protocol-REJ (as I would expect), instead it
sends Terminate-Acks, as answers to the DUN, which seems unlogical to me, but
is possible according to RFC's - maybe it happens because at the time DUN
starts CCP-Negotiations the MAX starts different negotiations and tries to tell
the DUN to reset the CCP.
This is okay so far - but what goes wrong ?
>From what I've seen in the logs I assume that the problem arises from different
opinons of the interpretation of the RFC's.
The DUN behaves correctly by retrying to negotiate the CCP (according to
RFC1331) after the timeout, but the MAX always gives the same answer:
"Terminate-Ack" - even if there is nothing else to do anymore (like IPCP and
alike). This behaviour seems not correct to me - the MAX should answer with an
appropriate Protocol-(ACK|NAK|REJ), but doesn't.....
The reason for this might be that the DUN sends always the same Packet-ID's,
which might make the MAX "think" that the previous "Terminate-Ack's" haven't
reached their target.
The RFC is a bit unclear about incrementing the Packet-ID's - it says that
Packet-ID's MUST be incremented when information is changed, but MAY be changed
when timeout occurs.
Well in this case timeouts occur - I assume the Ascend-OS-Implementors did a
different interpretation then the M$-Implementors did, so the sh.. happened.
There is no acknowledge-mechanism of the "please reset your protocol
negotiations" by sending "Terminate-Ack", so the different interpretations
could escalate.
I would suggest that the MAX-OS shall not assume that the "Terminate-Ack"
didn't reach it's target when not receiving higher packet-ID's - even if they
did not, there should be no problem, because the protocol negotiations time out
anyway.
Anyway - when finding a "MAY" in a RFC, shouldn't there be made no assumptions
and the software be programmed that way, that it is able cope with every
possible interpretation ? - Okay, no doubt, this is alway easier said than
done.
If anyones interested in the logs that made me think the above stated, let me
know, maybe someone finds a more correct solution !
--
MfG,
Lars Foerster,
Systemadministrator
-------------------------
/ eMail: lars@freeway.de \
- --------------------------------------------------
F r e e w a y N e t s e r v e r G m b H
- Internet Service Center -
Ludwig-Rinn-Str. 14-16
35452 Heuchelheim
Germany
Fon +49 641 9678-0
Fax +49 641 9678-12
eMail: info@freeway.de
------------------------------------ ------
\ "Never touch a running system !" /
----------------------------------
To assure mail consistency and authenticy:
PGP-Version: 2.6.3i
mQCNAzHGm7EAAAEEAMhUhXH8CbfLxeQCRRTnjA98dI9BmHPD9g8/3nIkOTLI87U4
EQnOJD1l8wICmYG2PI9EoZO7BvURrk3dxuz8dxYyG3xa/iCXfxabEq7RBNAgOpY/
niyIBwtLUiabPITHdG3seM/q/tjJFIAS6k8bH0niqcMc8ml2soGjEzlQX3gVAAUR
tB9MYXJzIEZvZXJzdGVyIDxsYXJzQGZyZWV3YXkuZGU+iQCVAwUQMcabsoGjEzlQ
X3gVAQHU0gP9FBTCzvQv2JSKIflHwpOCVXo1MB9QAfndoRKyHCGddEoBJ29FxBmX
3KleUkVBw4ZI6wZ4jngyCKjxEcy9Vw9eRf4zzUhMVa0aYTgf7fqOcYE6iqOrP6t3
kjVX8f3quzn+j9tbWVQI6p6QMUWOczUJHaQZok0TjyAHl6pTRK3K5Co=
=iKwu
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: