On Thu, 10 Feb 2000, Daniel Stenberg wrote:
|In my current project we have an edited pppd 2.3.7 running on Linux
Edited?
|(kernel 2.2.12) for incoming connections. We have custom drivers for an
|ISDN card and a multiport modem-card, both on PCI.
|
|Anyway, we have connected with Windows clients flawlessly for some time
|now and they always seem to connect and run fine (as fine Windows can
|run). The other day I connected with a Linux box and *bing* there was
|trouble:
|
|When the Linux client sends its PAP authentication package (with
|name+password), the server-side doesn't decode it properly and thus
|discards it and waits for another packet. The client side waits 3 seconds
|and resends the package that ends up arriving correctly in the server. I
|used pppd 2.3.11 in the Linux client which should be the latest and the
|greatest (?), so I don't suspect the client code. I also tried to connect
|with the Linux client to some ISPs and then it doesn't show the same
|failure.
|
|Looking at what differs from the Linux client and the Windows client when
|it comes to the "broken" decoded frame, it seems Linux is sending a
|84-byte package that looks like (at least this is what my TTY-driver
|reads):
|
|7e ff 7d 23 c0 21 7d 22 7d 21 7d 20 7d 3c 7d 21 7d 24 7d 21 28 7d 22 7d 26
|7d 20 7d 2a 7d 20 7d 20 7d 23 7d 24 c0 23 7d 25 7d 26 d8 38 ce 5e 7d 27 7d
|22 7d 28 7d 22 98 86 7e c0 23 01 01 00 15 08 69 6e 67 65 6d 61 72 73 07 63
|6f 6e 74 61 6b 69 ad 8f 7e
|
|The TTY-driver reads this chunk and passes it to the PPP NI that then
|deframes this. It first finds a valid PPP-frame that looks like:
|
| FF 03 C0 21 02 01 00 1C ...!....
| 01 04 01 28 02 06 00 0A ...(....
| 00 00 03 04 C0 23 05 06 .....#..
| D8 38 CE 5E 07 02 08 02 .8.^....
I it necessary to qualify this reply by saying that I've never been
involved in PPP implementation or design; I'm strictly an amateur who
happens to be interested in the details of PPP.
The last option in this LCP Configure-Request is the Address and Control
Field Compression option which requests the peer to send messages without
the AHDLC address and control fields, ff 03. If this request was ACKed by
the "edited" pppd then the peer could send subsequent messages - other than
LCP messages - without these fields although doing so is optional.
If the request was not ACKed then pppd seems to have used it prematurely,
although I can envison this being done in anticipation of an ACK and, in
case an ACK was not forthcoming, falling back to sending these fields.
This would seem to be a reasonable way to implement PPP since the peer is
not *required* to omit the fields even after ACKing the option.
| ... but then the rest of the data contains:
|
| c0 23 01 01 00 15 08 69 6e 67 65 6d 61 72 73 07 63 6f 6e 74 61 6b 69 ad
|8f 7e
|
|The PPP NI does not like this. (I'm guessing that) since there's no
|initial 7e in this frame, the decoder gets a bit confused and it assumes a
|bad frame that ends up like this (and gets discarded):
The 7e is a frame separator and there was already one at the end of the
preceding frame, just as there is one at the end of this frame. The 7e at
the beginning of the first frame is optional but many PPP implementation
include it. Consecutive frames can be, and often are, sent without 7e at
the beginning of the frames.
I just peeked at comp.protocols.ppp and see that James Carlson has answered
your post there in essentially the same way except he mentioned the ACCM as
a candidate for the problem too. James Carlson *is* a PPP guru.
---
Clifford Kite Not a guru. (tm)
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
