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)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:33:50 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,163 |