# TCP/UDP Checksum errors [Solved, sort-of]

## MadOtis

Hello all,

I recently rebuilt my desktop system that originally had Suse (SLED 10) intstalled on it.  I never had any network issues with Suse, just very restricted when it comes to software package support (i.e., older packages were the only ones supported, so, lots of bugs and limited functionality).

I have run Gentoo on my home machines for about 5 years now, so I am much more proficient with Gentoo than Suse.

Here's my problem...  Since installing Gentoo, my network connection has been very slow and several pages don't ever complete loading.  I can use SCP or SFTP to transfer SMALL files, but anything larger than about 300K causes SCP/SFTP to "stall".  I emerged wireshark to try and see what may be going on and I am noticing LOTS and LOTS of "TCP Checksum Errors" on just about any packet that goes outside of our corporate network (while only seeing a few from inside).  So, to try and eliminate the corporate network, I installed Wireshark on my XP laptop as well and navigated to the same sites that cause problems on my Gentoo box.  I don't see ANY checksum errors coming from the XP based laptop.  I have both laptop and desktop machines wired to a local hub while using the same cable to connect the hub to the wall-jack in my cubicle.  I've also swapped the network cables from the hub to each of the computers and I get the same results regardless of what port or cable I use.  So, this leads me to believe it's something in the Gentoo system and not the physical network (at least, the physical network I have access to).

I get the same symptoms if I boot a Gentoo LiveCD, but the network runs fine with no checksum errors if I boot a Suse LiveCD.  So, this and the previous tests lead me to think there is a configuration problem or setting I am missing somewhere in the Gentoo config or network driver.

here are the hardware particulars:

Computer: Dell Precision 490 - 4 way dual core Xeon CPUs at 3Ghz - 4gig Ram

Eth0:  Broadcom NetXtreme BGM5752 w/ tigon3 (tg3) kernel module

net configuration: DHCP, so, no real control over IP address or settings.

Aside form this network issue, the rest of the machine is functional and working as I expect it to.  So, if anyone can help me solve this, I would be greatly appreciative.  Any more information I can help provide, please let me know.

cheers!

RandyLast edited by MadOtis on Thu Jan 31, 2008 1:19 am; edited 1 time in total

----------

## Wormo

Disable offloading of checksums to hardware, there seems to be a problem with that feature for BCM5721 and tg3 as well:

http://thread.gmane.org/gmane.linux.network/59628/focus=59728

```

ethtool -K eth0 rx off

ethtool -K eth0 tx off

```

----------

## Seek

This is not necessarily a hardware problem.

Since your network card is calculating the checksums for you, wireshark is not able to check it, beause the packet is already about to leave your machine.

You can simply let wireshark ignore the checksum errors on outgoing packets.

Preferences -> Protocols -> TCP / UDP -> unset "Check the validity of the TCP / UDP checksum when possible"

I think your problem is descriped here:

http://wiki.wireshark.org/TCP_checksum_offload

Good luck!

----------

## MadOtis

Wormo, thanks, that was what I was looking for, but I don't think it is solving my problem...  While I'm not having very many checksum problems any longer, I still see the "stalls" in SCP/SFTP and web pages that seem to just simply stop.  I guess I'll keep digging...

Seek: Yes, I'm aware of the option to disable it in Wireshark...  but I was trying to solve the network issues and thought that the results of those checksum errors could have been causing some sort of "retry hell" on the network segment.  As it turns out, they aren't the issue anyway.

Cheers!

Randy

----------

## Wormo

Seek:

You're right that wireshark would show bad checksums whenever checksumming is offloaded to the hardware, so it does not in itself indicate a problem.

However, in this case there is a real networking problem not just the observation of checksum errors under wireshark. Looks like not only is checksum offload enabled, it also happens to be broken for certain broadcom cards, because the link I posted above was from a person using the tg3 driver and a similar card, and his networking problem was fixed by disabling checksum offloading (in both directions).

[edit]Rats, looks like this is not the same issue after all, since a new post appeared while I was writing this one. What are you seeing now from wireshark during stalls, could it be a tcp window problem?[/edit]

----------

## MadOtis

Yeah, I think that's the issue at this point...  I just changed the default MTU to "1500" and that has helped... it just takes longer to stall now.  I'll try experimenting with larger MTU values to see if I can find the magic number.

Thanks again for the help!

----------

