Bug 8409

Summary:	netfilter : checksum incorrect for eth0 but not for ppp0 packets
Product:	Networking	Reporter:	Toralf Förster (toralf.foerster)
Component:	Netfilter/Iptables	Assignee:	Jeff Garzik (jgarzik)
Status:	CLOSED INVALID
Severity:	normal	CC:	auke-jan.h.kok
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.20-gentoo-r7	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	the good the bad

Description Toralf Förster 2007-04-30 09:29:53 UTC

Most recent kernel where this bug did *NOT* occur:
Distribution: Gentoo (stale)
Hardware Environment: ThinkPad T41
Software Environment: Linux n22 2.6.20-gentoo-r7 #4 Sun Apr 29 14:05:29 CEST
2007 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux

Problem Description:
I'm wondering why the network packets I got from my ADSL line are ok from the
ppp0 interface but often have incorrect checksums if I sniff them at the eth0
interface (using wireshark).

Although the amount of the affected packets are reduced from kernel version
2.6.1[89] to the current kernel the problem still happens at least for all UDP
Microsoft messenger packets and for some other  TCP packets too.

The problem can be seen in the 2 attached pcap files I sniffed with tcpdump at
the same time, the 2 command lines at 2 different terminals were :

n22 ~ # tcpdump -i eth0 -s 0 -w tcpdump_eth0.pcap 
n22 ~ # tcpdump -i ppp0 -s 0 -w tcpdump_ppp0.pcap

Look at packets 2 and 3 of the 2 attached files for the messenger problem and
for packet 23 in tcpdump_eth0.pcap  respectivly packet 21 in tcpdump_ppp0.pcap

The 2nd case prevents the KDE application kgpg to return from a search for a
given gpg key b/c the kde application seems to ignore TCP packets having nota
correct checksum :-(



Might be it has something to do with my current firewall configuration (b/c here
 my reported issue was related rather to the netfilter module than to e1000
:http://bugzilla.kernel.org/show_bug.cgi?id=7938#c4 )

These are the modules I'm using:
n22 ~ # lsmod | grep -e nf_ -e ipt_ -e xt_
ipt_MASQUERADE          2560  2
xt_multiport            3136  12
ipt_REJECT              3392  1
xt_tcpudp               3264  29
ipt_recent              7920  6
nf_conntrack_irc        5732  0
nf_conntrack_ftp        8288  0
xt_state                1984  2
xt_limit                2112  3
ipt_LOG                 5696  3
nf_nat                 14444  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4      12492  4 iptable_nat
nf_conntrack           46888  7
ipt_MASQUERADE,nf_conntrack_irc,nf_conntrack_ftp,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
x_tables               11716  10
ipt_MASQUERADE,xt_multiport,ipt_REJECT,xt_tcpudp,ipt_recent,xt_state,xt_limit,ipt_LOG,iptable_nat,ip_tables


Steps to reproduce:

Comment 1 Toralf Förster 2007-04-30 09:30:33 UTC

Created attachment 11348 [details]
the good

Comment 2 Toralf Förster 2007-04-30 09:30:55 UTC

Created attachment 11349 [details]
the bad

Comment 3 Auke Kok 2007-04-30 14:00:32 UTC

Not sure that this is a bug. Your default route is over ppp0 and packets are
encapsulated. NAT and PPP drivers may alter the packet resulting in the csum not
being valid in the eth0 context when wireshark is looking at them, but actually
arrive properly over the wire. (otherwise the stack would discard them, right?)

Comment 4 Toralf Förster 2007-05-01 01:41:06 UTC

>when wireshark is looking at them
Oh no, I sniffed with tcpdump and used wireshark only for inspecting the stream.

Comment 5 Auke Kok 2007-05-01 08:35:47 UTC

change "wireshark" to "tcpdump" in my comment and re-read - I know that tcpdump
can't look at what actually goes out over the hardware (due to hardware
offloading and netfilter, encapsulation etc etc). 

Several non-bugs like this have already been filed in this bugzilla before.

Comment 6 Toralf Förster 2007-05-06 05:38:58 UTC

Ok, b/c the incomoing packets from ppp0 are ok in general and the same data from
interface eth0 have often bad checksum  it is rather a netfilter problem than
e1000, isn't it ?

Comment 7 Toralf Förster 2007-05-22 02:36:42 UTC

arrgh, this "issue" went away with "$>ethtool -K eth0 rx off tx off", sorry for
the noise

Comment 8 Toralf Förster 2007-09-05 07:15:39 UTC

Last comment wasn't true for all packets but BTW this issue is resolved actually (see http://bugzilla.kernel.org/show_bug.cgi?id=8793#c11)