> On Tue, 22 Dec 1998 11:14:51 -0500 (EST), Richard B. Johnson wrote:
>
> >On Tue, 22 Dec 1998, Doug Nazar wrote:
> >
> >> I've been seeing the for quite sometime, and I finally got a bit of time to look through the code. I haven't got quite the hang of it
> >> all yet.
> >
> >> Dec 22 06:46:48 linux02 kernel: csum=0xa479952d, ip_summed=0, nh=0xc107a09c, h=0xc107a0b0, data=0xc107a0b0
> >>
> >....err... The checksum isn't a longword (not an int on i386). It's
> >a short.
>
> include/linux/skbuff.h shows skb->csum as an unsigned it however it's
> irrevelant to my point. If the only time I see bad checksums is when
> the skb->h.raw == skb->data and where the final byte is 0xb0 then
> perhaps somewhere we are miscalculating something. This is providing
> that tcp_v4_rcv() is called for every packet which is what I was trying
> to determine.
>
Well it just may not be irrevelant. Where did the extra word come from?
It was supposed to have been folded back into the low word. The partial
checksum routine should have the top 16 bits clear (which it doesn't).
This means that if skb->csum is being used directly, without the
shifts and adds, it will be wrong. This should have been handled in
the 'asm' routine so that you never have the condition where an undetected
carry can occur. It sure can occur here where the top 16 bits are
allowed to warp. This can occur if you have longer than normal packets.
With the 'normal' 1500 MTU, you have roughly 1498 bytes to checksum
with a word checksum, that's 749 words. 749 * 65535 = 49,085,715 which
can fit in the 32-bit 'int' and not have an undetected overflow. If
the MTU is roughly 9 times this, your checksums will be calculated
wrong. Since there is now a concerted effort to increase the MTU on
a LAN far beyond the present, I strongly suggest that the `shift and
adds` be made within the partial checksum routine(s) so that the high
bits are always clear for intermediate as well as final values.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/