• pppd: unsupported protocols (only ping works)

    From trublemaker@gmail.com@21:1/5 to All on Fri Jul 27 06:31:08 2018
    Does this problem resolved?

    I meet the same problem.

    Jul 27 21:30:32 SUSE-mao pppd[83992]: Unsupported protocol 0x7374 received
    Jul 27 21:30:32 SUSE-mao pppd[83992]: sent [LCP ProtRej id=0x2a 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 ...]
    Jul 27 21:30:32 SUSE-mao pppd[83992]: rcvd [proto=0x7475] 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 ...
    Jul 27 21:30:32 SUSE-mao pppd[83992]: Unsupported protocol 0x7475 received
    Jul 27 21:30:32 SUSE-mao pppd[83992]: sent [LCP ProtRej id=0x2b 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 ...]


    在 2001年10月18日星期四 UTC+8下午3:32:24,Olaf Stetzer写道:
    James Carlson schrieb:

    Olaf Stetzer <ostetzer@mail.uni-mainz.de> writes:
    Maybe there is a problem with vj-decompression, I am not sure if this
    is implemented in pppd or do I need to compile a kernel module for that (though I haven't found one yet to configure)?

    I really think you're barking up the wrong tree with that. I
    mentioned before in this thread that VJ can't ever send or receive
    things without a proper PPP header. It's still true. VJ doesn't
    touch the PPP header, and thus cannot cause the header to go bad, and
    thus cannot cause LCP Protocol-Rejects.

    OK, sorry. I am really not an expert in these things, I only tried to interpret the observations I did.

    Oct 16 23:14:45 Merlin pppd[1341]: Unsupported protocol 'Stampede Bridging'
    (0x6f) received
    Oct 16 23:14:45 Merlin pppd[1341]: sent [LCP ProtRej id=0xb 00 6f 6f 73 65
    2e 64 74 64 22 3e 0d 0a 0d 0a 3c 68 74 6d 6c 3e 0d 0a 0d 0a 3c 68 65 61 64
    3e 0d ...]
    Oct 16 23:14:45 Merlin pppd[1341]: rcvd [proto=0x67] 68 6c 69 67 68 74 32 20 3d 20 6e 65 77 20 49 6d 61 67 65 28 29 3b 0d 0a 20 20 48 69 67 68 6c 69
    ...

    It looks very much to me like the peer is somehow sending you raw application data without the necessary TCP, IP, and PPP headers. This
    is horribly broken.

    One thing that could cause this is a peer MP (RFC 1990 Multilink PPP) implementation that (somehow) sends the wrong bits in the MP header -- mismarking the MP fragments as "beginning" when they're really in the middle of an IP datagram -- or a local implementation that manages to mishandle the MP header in an analogous way. This would result in intermediate fragments (which have no TCP/IP or inner PPP headers)
    being dispatched by PPP as mangled PPP packets, and would have exactly
    the symptoms you cite.

    In fact, the fact that small packets make it through OK but larger
    ones do not means that it's packet-size related, and MP fragmentation
    is certainly triggered by packet size on most implementations.

    Does this occur when MP is off (nomp)? What happens if you do nompshortseq?

    nomp does no effect, I forogt to try nompshortseq yesterday, I will
    try it this evening.

    Can you modify the peer's MP kernel bits to stop fragmenting? MP
    doesn't require fragmentation at all; it's merely an implementation
    option. If the peer sent each packet with MP headers, but with both B
    and E bits set (unfragmented), then you might avoid this problem.


    Ummmm, how do I do this? The peer is just an internet-by-call-provider,
    and intersetingly this happens with another provider I tried too.
    Maybe some important fact I forgot to mention: The modem-emulation
    of isdn4linux provides a way to set the protocol to HDLC. I had to
    set this option to get a connection to the provider at all. I also
    had to set the sync option (which is also HDLC) for pppd. Was this a
    correct setting/ combination of settings?

    Thanks,

    Olaf



    --
    Olaf Stetzer
    Forschungszentrum Karlsruhe
    Institut für Meterologie und Klimaforschung
    Atmosphärische Aerosole (IMK III) - http://imk-aida.fzk.de
    Tel.: +49(0)7247-82-3249 (FAX: -4332)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)