Hi all
This started out as what I thought is a problem in my code, but it has
turned out that it looks as if this could be a problem in the Linux pppd
code.
Let me take it from the start.
Part #1.
--------
In my current project we have an edited pppd 2.3.7 running on Linux
(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.^....
... 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):
FF 03 C0 23 69 6E 67 65 ...#inge
6D 61 72 73 63 6F 6E 74 marscont
61 6B 69 AD 8F aki..
... while the expected frame should have been:
FF 03 C0 23 01 01 00 15 ...#....
08 69 6E 67 65 6D 61 72 .ingemar
73 07 63 6F 6E 74 61 6B s.contak
69 i
Is it allowed to send two PPP frames next to each other without starting
the second frame with 7e like this? If it isn't, I guess there's something
wrong in my driver layer. It it is, there's a problem in the PPP NI
frame-decoder.
Also, is there a more low level way to snoop on the pppd read/write data
than the 'record' option? I would like to see the exact bytes that the
client sends to the modem so that I can verify that the client is actually
sending every single byte the way that my TTY-driver tells me it reads...
Part #2
-------
I noticed I used the 2.3.7 ppp-module in the client, so I installed the
2.3.11 one. I also added a little debug output that writes the packet to
the kernel log *after* it has been encoded in PPP-framing format.
What do I see there?
First out, the regular 'kdebug' output which seems correct:
ppp: write frame, count = 25
FF 03 C0 23 01 01 00 15 ...#....
08 69 6E 67 65 6D 61 72 .ingemar
73 07 63 6F 6E 74 61 6B s.contak
69 i
Then, my raw output. Notice the missing 7e prefixed one.
ppp: RAW FRAME, count = 26
C0 23 01 01 00 15 08 69 .#.....i
6E 67 65 6D 61 72 73 07 ngemars.
63 6F 6E 74 61 6B 69 AD contaki.
8F 7E .~
The receiving end does not understand it. The above package has as could
be seen in part #1, been appended to the one sent just before. (This is
probably due modem and driver packaging.)
Well, the 'server' doesn't respond to our name and password so it takes 3
seconds and then the client resends this package:
ppp: write frame, count = 25
FF 03 C0 23 01 02 00 15 ...#....
08 69 6E 67 65 6D 61 72 .ingemar
73 07 63 6F 6E 74 61 6B s.contak
69 i
... which looks like this when PPP-framed:
ppp: RAW FRAME, count = 27
7E C0 23 01 02 00 15 08 ~.#.....
69 6E 67 65 6D 61 72 73 ingemars
07 63 6F 6E 74 61 6B 69 .contaki
46 E6 7E F.~
The 7E is back. Is this a bug in the PPP-NI frame-encoder?
(Yes, I'm aware there's a user and plaintext password included here,
although you won't find anywhere to use them.)
--
Daniel Stenberg - http://www.contactor.se/~dast - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
