Hi I see wath is Your problem but I use pppd 2.3.7 and conect with my
modem at a CISCO router and first time when I conect the pppd send to my
log:
.... pppd[...] Protocol-Reject for unsuported protocol 0x5072
and this is not only problem but my logs is to big after that.
Can U teach me haw is protocol 0x5072 or haw or wher to change to disapere
this message from my log?
Thank's for Your time
Bogdan Daja
On Thu, 10 Feb 2000, Daniel Stenberg wrote:
> 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]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
