bad udp check sum on traceroute from box w/ NAT

teknogeek0 · n00b Joined: 30 Jul 2007 Posts: 1

OK, so here's a fun one.

I've been trying to troubleshoot a very odd traceroute/udp issue I'm seeing that I can't figure out.

I have two gateway/firewall boxes running NAT for internal hosts on two different networks (office1 and office2).
one is running 2.6.22-gentoo-r9, lets call this one gw1
the other 2.6.20-gentoo-r8, lets call this one gw2

Theres two other systems here:
a system inside either of these two lans, we'll call it lan_host1
a system out on the internet not behind nat, we'll call it outside1

From lan_host1 which is behind either gw1 or gw2 I can traceroute out fine. I can hit gw1 or gw2 from inside the opposites network, i can hit any other host on the internet ( including outside1 ).

From outside1 I can traceroute to both gw1 and gw2 no problem.

Whenever I try to traceroute from either gw1 or gw2 to any host on the internet, including each other and/or outside1, it eventually times out and fails. Running tcpdump on both hosts at the same time while doing the traceroute shows the same UDP packets at both ends, and I know that both hosts respond to traceroute otherwise. What is interesting is what tcpdump shows ( on both hosts ) of the packets in question:

Bones McCracker · Veteran Joined: 14 Mar 2006 Posts: 1611 Location: U.S.A.

I am not sure if this applies to tcpdump, but I imagine so, because both tcpdump and wireshark are based on libpcap.

Using wireshark, I saw a lot of "bad checksum" notices on packets. After researching this, I learned that this is because my network interface card is configured to use checksum offloading (where it hands of responsibility for checksumming to the CPU). This is a feature of most modern network interface cards, and it is configurable (you can turn it on or off). Because pcap is sniffing the packet at a point where the checksum has not yet been computed, it registers it as a "bad checksum".
http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html

In short, there is a good chance your traceroute problem has nothing to do with "bad checksums". If you want to confirm this, you can check and modify the network interface card's configuration using ethtool (see the man page):