TCPv4 checksum errors

TCPv4 checksum errors

[Geert Uytterhoeven]

There must be a bug left in the TCPv4 checksum code. Linux/PPC still sends
out packets with bad checksums. Any TCP checksum experts listening?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Paul Mackerras]

Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

> There must be a bug left in the TCPv4 checksum code. Linux/PPC still sends
> out packets with bad checksums. Any TCP checksum experts listening?

I have tried Dave Miller's checksum test program on the PPC inet
checksum code and it didn't find any errors.  Do you have an example
of a specific packet with a bad checksum generated by Linux/PPC?

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Martin Costabel]

Paul Mackerras wrote:
> 
> Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> 
> > There must be a bug left in the TCPv4 checksum code. Linux/PPC still sends
> > out packets with bad checksums. Any TCP checksum experts listening?
> 
> I have tried Dave Miller's checksum test program on the PPC inet
> checksum code and it didn't find any errors.  Do you have an example
> of a specific packet with a bad checksum generated by Linux/PPC?

I can get bad TCPv4 checksum errors very easily by telnetting to
dev.linuxppc.org. From /var/log/messages:

Dec 22 08:05:07 rennes-43 identd[19807]: Connection from
dev.linuxppc.org
Dec 22 08:05:12 rennes-43 identd[19807]: from: 169.207.161.2 (
dev.linuxppc.org ) for: 2526, 21
Dec 22 08:05:12 rennes-43 identd[19807]: Successful lookup: 2526 , 21 :
root.root 
Dec 22 08:05:52 rennes-43 kernel: TCPv4 bad checksum from
169.207.161.2:0017 to 193.252.125.43:09df, len=20/20/40
Dec 22 08:05:55 rennes-43 kernel: TCPv4 bad checksum from
169.207.161.2:0017 to 193.252.125.43:09df, len=20/20/40

Yesterday I got them also all the time while ftping from there. Today I
didn't see this.

--
Martin

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Geert Uytterhoeven]

On Tue, 22 Dec 1998, Paul Mackerras wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:
> > There must be a bug left in the TCPv4 checksum code. Linux/PPC still sends
> > out packets with bad checksums. Any TCP checksum experts listening?
> 
> I have tried Dave Miller's checksum test program on the PPC inet
> checksum code and it didn't find any errors.  Do you have an example

I tried his program a while ago, too, on m68k and PPC. According to that
program, the m68k checksum routines are broken, but PPC is OK. But I don't
believe it. I never get TCP checksum errors for packets originating from any
other machine.

People who don't have m68k boxes also see them for packets related to PPC
boxes. And I can't believe the ia32 checksum routines are broken, too.

> of a specific packet with a bad checksum generated by Linux/PPC?

cassandra kernel: TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.4:0201, len=20/20/40

(10.0.24.8 is CHRP, 10.0.24.4 is Amiga)

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[David S. Miller]

   Date: Tue, 22 Dec 1998 10:21:58 +0100 (CET)
   From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>

   > of a specific packet with a bad checksum generated by Linux/PPC?

   cassandra kernel: TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.4:0201, len=20/20/40

   (10.0.24.8 is CHRP, 10.0.24.4 is Amiga)

My suggestion is that since you can reproduce it, you should add code
next to this printk statement which dumps the entire packet in HEX to
the console.  Then you can see what and who is at fault and where.
If the packet is sufficiently small you can walk the checksum
algorithm by hand and verify it for this test case.

In any event this should allow you to say a lot more about this
situation, I hear about it a lot and if I were a PPC or m68k developer
I would not let it go for this long, especially if I could reproduce
it on my own friggin' machine!

BTW, do all of the PPC's which exhibit the behavior use the same
ethernet controller?

Later,
David S. Miller
davem@dm.cobaltmicro.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Geert Uytterhoeven]

On Tue, 22 Dec 1998, David S. Miller wrote:
>    Date: Tue, 22 Dec 1998 10:21:58 +0100 (CET)
>    From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
> 
>    > of a specific packet with a bad checksum generated by Linux/PPC?
> 
>    cassandra kernel: TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.4:0201, len=20/20/40
> 
>    (10.0.24.8 is CHRP, 10.0.24.4 is Amiga)
> 
> My suggestion is that since you can reproduce it, you should add code
> next to this printk statement which dumps the entire packet in HEX to
> the console.  Then you can see what and who is at fault and where.
> If the packet is sufficiently small you can walk the checksum
> algorithm by hand and verify it for this test case.

Which one do I have to dump? skb->h.raw or skb->nh.raw? I guess
skb->nh.iph->tot_len bytes at skb->nh.raw?

> In any event this should allow you to say a lot more about this
> situation, I hear about it a lot and if I were a PPC or m68k developer
> I would not let it go for this long, especially if I could reproduce
> it on my own friggin' machine!

:-)

Well, it's not `reproducible on demand'. It happens from time to time.

> BTW, do all of the PPC's which exhibit the behavior use the same
> ethernet controller?

Yes, we all have Tulip boards (I think >95% of the PPC users have Tulip
boards). And the message on linux-kernel about checksum errors on ARM related
to Tulip made me suspicious at well...

If it may help: my Amiga has an Am79C960 (little endian LANCE with byte swapped
data bus).

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[David S. Miller]

   Date: Tue, 22 Dec 1998 11:01:13 +0100 (CET)
   From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>

   On Tue, 22 Dec 1998, David S. Miller wrote:
   > My suggestion is that since you can reproduce it, you should add code
   > next to this printk statement which dumps the entire packet in HEX to
   > the console.  Then you can see what and who is at fault and where.
   > If the packet is sufficiently small you can walk the checksum
   > algorithm by hand and verify it for this test case.

   Which one do I have to dump? skb->h.raw or skb->nh.raw? I guess
   skb->nh.iph->tot_len bytes at skb->nh.raw?

Look at what the code next to the printk is verifying:

		skb->csum = csum_partial((char *)th, len, 0);
		if (tcp_v4_check(th,len,skb->nh.iph->saddr,skb->nh.iph->daddr,skb->csum))

So you need all the bytes from 'th' to 'th + len'.  You also need the
values of the source and destination addresses from the IP header (at
skb->nh.iph->{saddr,daddr}).

Good luck.

Later,
David S. Miller
davem@dm.cobaltmicro.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Arno Griffioen]

> > BTW, do all of the PPC's which exhibit the behavior use the same
> > ethernet controller?
> 
> Yes, we all have Tulip boards (I think >95% of the PPC users have Tulip
> boards). And the message on linux-kernel about checksum errors on ARM related
> to Tulip made me suspicious at well...

Suggestion: 

Perhaps you should try some tests with an Amiga/PPC machine. That definitely
doesn't use the Tulip board, but is PPC based. Can't help you there yet
though as Linux/PPC dies with a machine-check when I try to access 
the brain-dead ISA NE2000 in my machine.

Should give some clue about either the PPC checksum-computation or
the ethernet card doing 'nasty things'.

								Bye Arno.

-- 
Internet Exchange Europe B.V.Fax: +31-70-3630470 | One disk to rule them all,
Lange Voorhout 9             Tel: +31-70-3600379 | One disk to bind them,
2514EA Den Haag +--------------------------------+ One disk to hold the files
The Netherlands |   * END OF TRANSMISSION *      | And in the darkness grind 'em
----------------+--------------------------------+------------------------------

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Geert Uytterhoeven]

On Tue, 22 Dec 1998, David S. Miller wrote:
>    Date: Tue, 22 Dec 1998 11:01:13 +0100 (CET)
>    From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
> 
>    On Tue, 22 Dec 1998, David S. Miller wrote:
>    > My suggestion is that since you can reproduce it, you should add code
>    > next to this printk statement which dumps the entire packet in HEX to
>    > the console.  Then you can see what and who is at fault and where.
>    > If the packet is sufficiently small you can walk the checksum
>    > algorithm by hand and verify it for this test case.
> 
>    Which one do I have to dump? skb->h.raw or skb->nh.raw? I guess
>    skb->nh.iph->tot_len bytes at skb->nh.raw?
> 
> Look at what the code next to the printk is verifying:

Ooch, didn't notice there was no `break' in between the two cases...

> 		skb->csum = csum_partial((char *)th, len, 0);
> 		if (tcp_v4_check(th,len,skb->nh.iph->saddr,skb->nh.iph->daddr,skb->csum))
> 
> So you need all the bytes from 'th' to 'th + len'.  You also need the
> values of the source and destination addresses from the IP header (at
> skb->nh.iph->{saddr,daddr}).

Thanks! Rebooting...

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Geert Uytterhoeven]

On Tue, 22 Dec 1998, David S. Miller wrote:
>    Date: Tue, 22 Dec 1998 10:21:58 +0100 (CET)
>    From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
> 
>    > of a specific packet with a bad checksum generated by Linux/PPC?
> 
>    cassandra kernel: TCPv4 bad checksum from 10.0.24.8:03ff to 10.0.24.4:0201, len=20/20/40
> 
>    (10.0.24.8 is CHRP, 10.0.24.4 is Amiga)
> 
> My suggestion is that since you can reproduce it, you should add code
> next to this printk statement which dumps the entire packet in HEX to
> the console.  Then you can see what and who is at fault and where.
> If the packet is sufficiently small you can walk the checksum
> algorithm by hand and verify it for this test case.

In the mean time I got this from a `new' PPC hacker. I haven't tried it yet
(still have to manually calculate checksums for my bad packets, too, sigh).

--------------------------------------------------------------------------------
>From VANDROVE@vc.cvut.cz Wed Dec 23 10:11:44 1998
Date: Tue, 22 Dec 1998 16:44:01 MET-1
From: Petr Vandrovec Ing. VTEI <VANDROVE@vc.cvut.cz>
To: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
Subject: PPC checksumming...

Hello Geert,
  I've found that Motorola Powerstack is much more happy after
applying folowing patch:

diff -ur linux/include/asm-ppc/checksum.h linux/include/asm-ppc/checksum.h
--- linux/include/asm-ppc/checksum.h Thu Apr 23 02:35:41 1998
+++ linux/include/asm-ppc/checksum.h    Tue Dec 22 16:19:49 1998
@@ -83,13 +83,13 @@
                           unsigned int sum)
 {
     __asm__("
-   add %0,%0,%1
-   add %0,%0,%2
-   add %0,%0,%0
-   addi %0,%0,0
+   addc %0,%0,%1
+   adde %0,%0,%2
+   adde %0,%0,%3
+   addze %0,%0
    "
    : "=r" (sum)
-   : "r" (daddr), "r"(saddr), "r"((ntohs(len)<<16)+proto*256), "0"(sum));
+   : "r" (daddr), "r"(saddr), "r"((proto<<16)+len), "0"(sum));
     return sum;
 }


Before applying, I've got TCPv4 bad checksum instead of Connection refused,
now it works :-) and I finnaly found that on my PPC inetd was not started...
But because of I'm learning PPC assembler only since today morning, I'm not
sure whether it does what I think it should... If you find it useful,
please post it to appropriate maintainer (DaveM or ... ?) I do not know,
who invented original code, maybe Cort (according to comments around code),
but it was not taken from linux/include/asm-sparc - I'm pretty sure :-)

With regards to matroxfb: I've found that PPC Bios did not assign addresses
to Matrox : framebuffer was located at 0xFF800000, MMIO at FFFFC000,
both overlapping itself :-( Unfortunately, after going through PREP PCI code
they were relocated to 0x01800000 and 0x01FFC000 - still overlapping, but
now values looks `normal' :-( And, it is worse, it looks like that
only region 0x01000000 - 0x01FFFFFF is forwarded into PCI bus, so there
is really resource starvation here... One 8MB framebuffer, 16KB MMIO,
some MMIO of NCR825... Life is not simple.
                                                                    Petr
--------------------------------------------------------------------------------

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Gabriel Paubert]

On Wed, 23 Dec 1998, Geert Uytterhoeven wrote:

> In the mean time I got this from a `new' PPC hacker. I haven't tried it yet
> (still have to manually calculate checksums for my bad packets, too, sigh).
> 
> --------------------------------------------------------------------------------
> >From VANDROVE@vc.cvut.cz Wed Dec 23 10:11:44 1998
> Date: Tue, 22 Dec 1998 16:44:01 MET-1
> From: Petr Vandrovec Ing. VTEI <VANDROVE@vc.cvut.cz>
> To: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
> Subject: PPC checksumming...
> 
> Hello Geert,
>   I've found that Motorola Powerstack is much more happy after
> applying folowing patch:
> 
> diff -ur linux/include/asm-ppc/checksum.h linux/include/asm-ppc/checksum.h
> --- linux/include/asm-ppc/checksum.h Thu Apr 23 02:35:41 1998
> +++ linux/include/asm-ppc/checksum.h    Tue Dec 22 16:19:49 1998
> @@ -83,13 +83,13 @@
>                            unsigned int sum)
>  {
>      __asm__("
> -   add %0,%0,%1
> -   add %0,%0,%2
> -   add %0,%0,%0
> -   addi %0,%0,0
> +   addc %0,%0,%1
> +   adde %0,%0,%2
> +   adde %0,%0,%3
> +   addze %0,%0
>     "
>     : "=r" (sum)
> -   : "r" (daddr), "r"(saddr), "r"((ntohs(len)<<16)+proto*256), "0"(sum));
> +   : "r" (daddr), "r"(saddr), "r"((proto<<16)+len), "0"(sum));
>      return sum;
>  }
> 
> 
> Before applying, I've got TCPv4 bad checksum instead of Connection refused,
> now it works :-) and I finnaly found that on my PPC inetd was not started...
> But because of I'm learning PPC assembler only since today morning, I'm not
> sure whether it does what I think it should... If you find it useful,
> please post it to appropriate maintainer (DaveM or ... ?) I do not know,
> who invented original code, maybe Cort (according to comments around code),
> but it was not taken from linux/include/asm-sparc - I'm pretty sure :-)

This patch looks very reasonable. You absolutely need the carry for TCP
checksums. 

> With regards to matroxfb: I've found that PPC Bios did not assign addresses
> to Matrox : framebuffer was located at 0xFF800000, MMIO at FFFFC000,
> both overlapping itself :-( Unfortunately, after going through PREP PCI code
> they were relocated to 0x01800000 and 0x01FFC000 - still overlapping, but
> now values looks `normal' :-( And, it is worse, it looks like that
> only region 0x01000000 - 0x01FFFFFF is forwarded into PCI bus, so there
> is really resource starvation here... One 8MB framebuffer, 16KB MMIO,
> some MMIO of NCR825... Life is not simple.

What is your machine ? Can you try to embed you /usr/src/vmlinux
in my (relatively new) preploader found at:

	ftp://vcorr1.iram.es/pub/preploader.tgz

Instructions:

tar xvzf preploader.tgz
cd preploader
make

provided your source tree is /usr/src/linux. You will get a zImage in
the preploader directory. This bootloader should reassign all I/O and
PCI memory space to something sane (provided you don't have any PCI<->PCI
bridges, not yet supported). However some S3 chips for example are buggy:
they claim they need 8Mb but actually need 64Mb. The bootloader includes
a black list to correct for this (one entry only up to now). 

	Gabriel.

P.S.: the output of lspci on your machine would be useful to help with
these problems. I'm also surprised that you only have 16Mb of MMIO
forwarded to PCI.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Alan Cox]

The classic bad packet error is a frame that ends up with

checksum =FFFF end around carry left =1

because you need to do two end around carries

(FFFF        1)
(0000	     1)
(0001        0)

at the end of a checksum

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Paul Mackerras]

Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

> In the mean time I got this from a `new' PPC hacker. I haven't tried it yet
> (still have to manually calculate checksums for my bad packets, too, sigh).

> diff -ur linux/include/asm-ppc/checksum.h linux/include/asm-ppc/checksum.h
> --- linux/include/asm-ppc/checksum.h Thu Apr 23 02:35:41 1998
> +++ linux/include/asm-ppc/checksum.h    Tue Dec 22 16:19:49 1998
> @@ -83,13 +83,13 @@
>                            unsigned int sum)
>  {
>      __asm__("
> -   add %0,%0,%1
> -   add %0,%0,%2
> -   add %0,%0,%0
> -   addi %0,%0,0
> +   addc %0,%0,%1
> +   adde %0,%0,%2
> +   adde %0,%0,%3
> +   addze %0,%0
>     "
>     : "=r" (sum)
> -   : "r" (daddr), "r"(saddr), "r"((ntohs(len)<<16)+proto*256), "0"(sum));
> +   : "r" (daddr), "r"(saddr), "r"((proto<<16)+len), "0"(sum));
>      return sum;
>  }

Aargh, I checked arch/ppc/lib/checksum.S thoroughly but I missed this
one!  Of course it needs to be addc/adde/adde/addze.  Kudos to Petr
Vandrovec (good spotting, as Linus would say).

Paul.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[David S. Miller]

   From: Alan Cox <alan@cymru.net>
   Date: Wed, 23 Dec 1998 21:58:04 +0000 (GMT)

   The classic bad packet error is a frame that ends up with

   checksum =FFFF end around carry left =1

I challenge you to generate a packet which will create this condition,
it is impossible as far as I have tried....

However, I'm very very interested in being proved wrong.  Because if I
am, then every single checksum implementation in the kernel would need
to be fixed and we should therefore settle this asap.

Instead of tiring one's brain like I did, to find if the case even
exists, better would probably be to put a piece of debugging code
which checked for this condition and printed out a nice message and
dumped the packet contents when triggered.

Later,
David S. Miller
davem@dm.cobaltmicro.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Andreas Schwab]

Alan Cox <alan@cymru.net> writes:

|> The classic bad packet error is a frame that ends up with
|> 
|> checksum =FFFF end around carry left =1

There can never be a carry if the sum is FFFF.  A sum of two 16 bit values
is never be bigger than 1FFFE.

Andreas.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Alan Cox]

> Alan Cox <alan@cymru.net> writes:
> 
> |> The classic bad packet error is a frame that ends up with
> |> 
> |> checksum =FFFF end around carry left =1
> 
> There can never be a carry if the sum is FFFF.  A sum of two 16 bit values
> is never be bigger than 1FFFE.

(2 previous + previous carry)

But you can show (and I sent Dave) the proof you must start in that
situation not at a sum of zero.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: TCPv4 checksum errors

[Andreas Schwab]

Alan Cox <alan@cymru.net> writes:

|> > Alan Cox <alan@cymru.net> writes:
|> > 
|> > |> The classic bad packet error is a frame that ends up with
|> > |> 
|> > |> checksum =FFFF end around carry left =1
|> > 
|> > There can never be a carry if the sum is FFFF.  A sum of two 16 bit values
|> > is never be bigger than 1FFFE.
|> 
|> (2 previous + previous carry)

You can only get in this situation if you start off with a carry in the
first place, and all other values are FFFF.  Also remember that an IP
packet is <= 65535 octets, or <= 32768 16 bit words (hexets?).  Thus you
can never get more than 32767 carries, which you can collect in a single
16 bit word, which is one of the values in the final folding round.

Andreas.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]