Summary: | Traceroute - Sending packets with checksums incorrect | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John Jaeger <billybobsa> |
Component: | Current packages | Assignee: | Eldad Zack (RETIRED) <eldad> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bsd+disabled, jkt, netmon, ninex, philippe |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | traceroute-1.4_p12-r6.ebuild (patched) |
Description
John Jaeger
2006-12-22 09:54:41 UTC
Reproducible on the latest kernel, currently 2.6.19? (In reply to comment #1) > Reproducible on the latest kernel, currently 2.6.19? > Yes, even though I had to over ride the ~amd64. Exactly the same. Linux athlon 2.6.19-gentoo-r2-Prod-2 #1 SMP Mon Dec 25 19:46:47 MST 2006 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux I'm having the same problem. I added some debugging code to traceroute; traceroute is calculating different checksums for each packets, but by the time tcpdump displays them and they go across the network, they all have the same invalid checksum. I have noted: 1. Disabling IP (not UDP!) checksums by passing "-x" to traceroute fixes the problem. 2. Specifying an explicit source address by passing "-s 12.34.56.78" to traceroute fixes the problem. 3. Specifying an interface to get the source address from by passing "-i eth1" to traceroute does not fix the problem. 4. Changing the address assigned to the interface on which the packets are being sent changes the invalid checksum. From this, I would guess that when traceroute allows the kernel to select the source address, it accidentally overwrites the checksum field. My guess is that some function in the kernel accesses part of the address as a native type such as int or long, and on a 64-bit system the variable is larger than expected. But I'm just a lowly user. Perhaps we should pass this to the kernel folks if it is, indeed, a real bug? By the way, packets sent by netcat have valid checksums, and packets sent by traceroute-nanog have no checksum, so those programs both work. Maybe comparing the ways they send UDP packets would reveal what traceroute is doing wrong itself and/or what traceroute is doing to trigger a kernel bug. thanks for the follow up info. You'd think they would pass this up the chain. I was beginning to think I was the only one with this issue... Me a lowly user too ;) comment #3 seems to suggest that only traceroute frames have incorrect checksums, whereas comment #0 seems to be talking about ALL network traffic. Is this correct? If so, these are 2 separate bugs. RE: Comment 0. From what I can see, traceroute is the only net program I have had difficulty with. Everything else seems peachy keen... BTW, traceroute -x host.domainname.com also works on my machine as it does not generate the checksums... I confirm this behavior on different platform with gentoo kernel x86 kernel gentoo 2.6.18-r3 x86 kernel gentoo 2.6.19-r2 but work on amd64 with gentoo kernel 2.6.18-gentoo-r2 each machine have different kind of network interface Also the strange thing i see with this is that kernel netfilter doesn't honor snat rules for this kind of packet. I have his rules on firewall /sbin/iptables -A POSTROUTING -t nat -o $PUB_DEV -s $INTERNAL_NET -j SNAT --to-source $PUB_IP rules is correctly done for traceroute with -x or -s argument but not for normal traceroute just to clarify my previous comment. When i say that netfilter snat is not honored i mean that the packet is send on the output interface with address from internal net. one of my colleague removed the following patch from the ebuild epatch ${FILESDIR}/${PN}-1.4a12-let_kernel_find_address.patch i did the same and traceroute work correctly. So the problem can be the patch or a kernel bug. Eldad, any thoughts on this? This is a traceroute bug introduced by a patch from bug #131723 Carlos and others tracked this down on IRC: traceroute is generating UDP checksums with the sender IP address of zero, then expecting the kernel to fill in the sender address thus making the checksum invalid Ahh, makes sense. it's sending packets using the raw socket. I'll have a look. Daniel, perhaps we should retract the let-kernel-assign-address patch until I can fix this proper? alright, I got a fix. This will disable checksumming when there is no address specified. the patch is here: http://dev.gentoo.org/~eldad/patches/26_all_traceroute-1.4a12-let_kernel_find_address_chksum.patch Created attachment 129097 [details]
traceroute-1.4_p12-r6.ebuild (patched)
Test this ebuild and see if it fixes it.
The is a *new* package net-analyzer/traceroute-2.0.8-r2. Thank Mike Frysinger for digging up http://archives.gentoo.org/gentoo-dev/msg_144535.xml this package and pushing it into the tree. It should fix this issue. The only problem I see is the following note in net-analyzer/traceroute ChangeLog: 05 Sep 2007; Roy Marples <uberlord AT gentoo.org> traceroute-2.0.8.ebuild: Version 2 looks like it's Linux only, so FreeBSD keywords are dropped. But do we have this bug in FreeBSD? Will applied patch fix the issue? Roy, could you tell us, please? Cool Beans. traceroute-2.0.8-r2 fixed it on my amd64 X2 boxes and one amd64 single core. Thanks so much... John (In reply to comment #15) > But do we have this bug in FreeBSD? Will applied patch fix the issue? Roy, > could you tell us, please? Sorry for the delay, had big trouble getting wireshark working. Anyway, it's working now and the result is ..... unsure. Whilst unpatched it is generating an invalid checksum, with the patch outbound packets have NO checksum which I'm sure isn't optimal either. FreeBSD traceroute does the same thing, so I'd say the patch is good for us too. Finally this bug is FIXED. Thank you Eldad for the fix, Roy for tests and all others who reported / worked here! |