>>> The search for TCPv4 bad checksums continues. adding novj to the
>>> ppp options seems to have fixed the problem. Still doing more
>>> testing to ensure that the router (the remote point of my point
>>> to point) has a bad ppp implementation and not me. Since it has a
>>> bad finger implementation, and ppp works fine over null modems
>>> and telnet sessions, I dare say the problem is with the router.
>> Probably a useful check is to find out if the "bad Van J
>> compression" problem is bad in the same way each time. If so, then
>> it could be an idea to include some sort of workaround for it in
>> the PPP routines, similar to the way we've worked round the F00F
>> bug rather than insist that users upgrade...
> Just to make sure I understand you, are you suggesting I mkae sure
> the bad VJ compressed packtes are only slightly bad and add code to
> ppp to "clean them up" if they come in bad? I think the packets are
> truncated, but I'll look into it. I need to read up on PPP though
> before I analyze the PPP packets too closely.
I was thinking of something along the lines of the following 'thought
process' being carried out by the computer...
Q> "Ah, we have a packet to send to Bad.Route.Net - let's see,
Q> there's 16k of data - VJ is enabled, and we already know
Q> the far end of my PPP link supports it, so let's use it."
Q> "No acknowledgement? OK, we'll assume it got corrupted in
Q> transit, and resend it. There, off it goes again."
A while later...
Q> "FIVE repeats! This is getting ridiculous! Hang on, wasn't
Q> there something about routers with faulty VJ compression a
Q> while back? Wonder if that's it - let's try disabling VJ
Q> compression and see if that helps..."
Q> "Ah, the link's working now. Better log a message reporting
Q> that the router at the far end of this PPP link appears to
Q> be susceptible to that particular bug. Might be an idea to
Q> note the fact for my own reference as well, so next time I
Q> get that particular router, I will know not to use VJ..."
Does that help?
Likewise, a case where we received lots of CONSECUTIVE bad checksums
from a particular router could be dealt with by a similar process...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/