Bug 129778 - tcpdump reports 'bad udp cksum' for valid domain packets - promiscuous mode problem?
tcpdump reports 'bad udp cksum' for valid domain packets - promiscuous mode ...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-12 13:11 EDT by Jason Vas Dias
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-12 15:54:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump.log (1.88 KB, text/plain)
2004-08-12 13:13 EDT, Jason Vas Dias
no flags Details
lookup.c (557 bytes, text/plain)
2004-08-12 13:14 EDT, Jason Vas Dias
no flags Details

  None (edit)
Description Jason Vas Dias 2004-08-12 13:11:58 EDT
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
(2.6.6-1.435) .

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.

How reproducible:

100%

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
or
  $ 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
4.
  $ pkill tcpdump

Actual Results: 

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.
  
Expected results:

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.


Additional info:

See attached tcpdump.log
Comment 1 Jason Vas Dias 2004-08-12 13:13:24 EDT
Created attachment 102661 [details]
tcpdump.log
Comment 2 Jason Vas Dias 2004-08-12 13:14:01 EDT
Created attachment 102662 [details]
lookup.c
Comment 3 David Miller 2004-08-12 15:54:14 EDT
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
checksumming occurs.

Sorry, but this is how it works.

Note You need to log in before you can comment on or make changes to this bug.