Description of problem:
tcpdump consistently reports "bad udp cksum" errors for all
domain (nameserver) packets generated by the localhost,
whether generated by resolver (glibc) or by named (bind),
even though these packets are evidently valid (they go out on
the wire and return valid responses).
Version-Release number of selected component (if applicable):
This happens both with kernel-2.6.7-1.509 and kernel-2.6.7-1.517.
I've tried the both the current FC3 tcpdump (tcpdump-3.8.2-5)
and the FC2 tcpdump (tcpdump-3.8.2-3) with both the above kernels,
with identical results.
This does NOT happen with tcpdump-3.8.2-3 and the FC2 kernel
I'm using a new IBM ThinkPad T41 with the e1000 driver controlling
an "Intel 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)"
("Class 0280: 14b9:a504").
domain packets seen on the wire from other machines are also reported
by tcpdump as having "bad udp cksum".
I thought the kernel is meant not to send packets with invalid
checksums on the wire, nor would a receiver of such a packet
pass it to a socket to be handled; so when it is sent, it has a
valid checksum, but when tcpdump gets it, it does not - so it looks
to me like a 'Promiscuous Mode' problem.
Steps to Reproduce:
1. ensure 'nscd' is shut down
$ service nscd stop
2. Run tcpdump to show domain packets
$ tcpdump -nl -vv -xx -i eth0 -s 1500 port domain > /tmp/tcpdump.log&
3. Do a host query - either run :
$ nslookup www.redhat.com
$ host www.redhat.com
(These bypass glibc resolver)
or use glibc resolver - compile attached "lookup.c" :
$ gcc -o lookup lookup.c
$ ./lookup www.redhat.com
$ pkill tcpdump
Look at /tmp/tcpdump.log (attached) - every domain packet generated
on the localhost is reported as having 'bad udp cksum', even though
they go out on the wire and return valid responses.
Valid packets that are sent out on the wire by the kernel cannot
have bad UDP checksums - tcpdump should not be getting mangled
packets and reporting that they have bad udp checksums if they
have been passed for sending by the kernel.
See attached tcpdump.log
Created attachment 102661 [details]
Created attachment 102662 [details]
If the card is going to checksum the UDP/TCP packet for
us (which it will with your e1000 card and current drivers)
then tcpdump is going to get a copy of the packet before
Sorry, but this is how it works.