Re: IPv4 checksum errors
Shane Anderson (shane@nve.com)
Wed, 26 Nov 1997 10:14:32 -0500
> Hi everybody,
>
> I recently sent this question to linux-net only, but have not gotten any
> reply so far, so this time I'll bring it in a somewhat larger audience,
> it's really weird, I saw these in my dmesg output:
>
> TCPv4 bad checksum from 205.229.196.5:0017 to 208.196.141.34:28ee,
> len=20/20/40
> TCPv4 bad checksum from 128.214.248.6:12e0 to 208.196.141.34:0019,
> len=1349/1349/1369
> TCPv4 bad checksum from 128.214.248.6:12e0 to 208.196.141.34:0019,
> len=425/425/445
> TCPv4 bad checksum from 128.214.248.6:0ef2 to 208.196.141.34:0019,
> len=1480/1480/1500
>
> The first address is from my ISP, so I can imagine something with that,
> the 128.* numbers are nic.funet.fi.... I don't remember contacting there
> lately at all, and I'm curious where these packets come from, or issit
> possible that the packet is so malformed that the IP address is not
> reliable anymore? Can this in any way be related to teardrop attack? Let
> me know if I can give more information.
I've had a similar problem. Try turning of VJ Header compression in
pppd (I'm assuming that's what you're using.) The len=X/X/X part
tells me that the length is off by 20 which just happens to be the
size of a header. Add '-vj' to your pppd cmdline or the ppd options
file.
So I'll bet that will solve your problem. But, things won't be truly
*CORRECT*. My guess is that there is a problem in the networking
code that doesn't correctly rebuild fragmented packets when VJ header
compression is used. I'm still running with '-vj' and I'd much
rather have that bandwidth if I could. (Not that the 1-2% the header
uses is too terribly much... but hey.)
-= shane.anderson@infrasol.com ======== Infrared Solutions, Inc. =-