Re: Van J compression?
Ian Eure (ieure@crosssound.narrows.com)
Tue, 29 Dec 1998 13:41:24 -0800
Riley Williams wrote:
>
> Hi Jack.
>
> >>> 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...
>
I've fought with ipv4 checksum errors a few times before. I have had it
caused by bad modems, bad external modem cables, bad phone (RJ11)
cables, and slow systems. Replacing the part, or using IRQTune to give
the modem IRQ the highest priority made things work better. And I have
run into one case where the remote end had a problem. Turning off VJ
compression fixed things. IIRC, the other end of the link was a
Livingston PortMaster.
Just my $.02
--
______________________________________________________________
| ian eure, network admin, freelance security consultant, and |
| manically depressed paranoid schizophrenic, at your service. |
; <ieure@minion.org> - http://minion.org ;
: raw speed = 105.6 wpm with 4.5% errors :
. . . . . . . . . . . . . . . . . . . . . .
-
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/