Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.protocols.ppp > #120

Re: pppd: unsupported protocols (only ping works)

Show all headers | View raw

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)

Back to comp.protocols.ppp | Previous | Next | Find similar

Thread

Re: pppd: unsupported protocols (only ping works) trublemaker@gmail.com - 2018-07-27 06:31 -0700

csiph-web