Bug 438458 - checksums incorrect for TCP/IPV6 packets with payload
checksums incorrect for TCP/IPV6 packets with payload
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tcpdump (Show other bugs)
5.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Michal Sekletar
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-20 23:47 EDT by Marco Grigull
Modified: 2011-09-29 11:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-29 11:13:56 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)
captured ssh session between rhel5 and openbsd (11.25 KB, application/octet-stream)
2008-03-20 23:54 EDT, Marco Grigull
no flags Details

  None (edit)
Description Marco Grigull 2008-03-20 23:47:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20080213 Red Hat/1.5.0.12-11.el5_1 Firefox/1.5.0.12

Description of problem:
tcp/ipv6 packets generated by the linux kernel, when conatining a payload (such as ssh or imap traffic) have an incorrect TCP checksum.  Syn, Ack and Fin packets not containing payload have correct checksum,



Version-Release number of selected component (if applicable):
kernel-2.6.18-53.1.14.el5

How reproducible:
Always


Steps to Reproduce:
1. setup packet capture on RHEL5 system
2. ssh to (or from) system using link-local ipv6 address (ssh ipv6_addr%eth0)
3. ssh and other protocols appear to work as expected, it is suspected that the checksum is ignored?

Actual Results:
observe captured packets using wireshark or tcp dump.  Wireshark will invert packet events with failed checksum; tcpdum -v will only show acknoledgement on good packets (and not bad)

Expected Results:
all packets should appear to have correct chksum.

Additional info:
The initial testing was done on dovecot, ssh between rhel5 systems was tested next.  Wireshark disector/libpcap as the issue was isolated by setting up openbsd as an ipv6 reference platform inside a xen guest parallel to the first test system.

Openbsd always generated the correct chksum.

From the behaviour observed, it is suspected that the TCP payload portion is either not checked correctly (wrong bounds?) or ommitted entirely from the calculation
Comment 1 Marco Grigull 2008-03-20 23:54:56 EDT
Created attachment 298766 [details]
captured ssh session between rhel5 and openbsd
Comment 2 Marco Grigull 2008-03-21 00:03:05 EDT
Also tested against debian x86_64 with 2.6.21 kernel, no issue on the debian side.
Comment 3 Marco Grigull 2008-03-21 00:10:40 EDT
RHEL4u5 Linux dhcp-64-190.bne.redhat.com 2.6.9-55.ELxenU #1 SMP Fri Apr 20
16:56:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

Rhel4 system not affected
Comment 4 Marco Grigull 2008-03-21 00:11:39 EDT
I had also originally seen this issue on bare metal install of RHEL5, all
subsequent investigations done as XEN guests.
Comment 5 Tomas Hoger 2008-03-21 08:24:30 EDT
Marco, have you been capturing packets on source or target machine?  Have you
used same hardware for tests with RHEL5, RHEL4 and Debian?

You may want to have a look at:

  http://kbase.redhat.com/faq/FAQ_40_11677.shtm
  http://wiki.wireshark.org/TCP_Checksum_Verification
Comment 6 Marco Grigull 2008-03-24 20:42:57 EDT
Hi Tomas,
The RHEL5 system is a fullvirt Xen guest, AFAIK no tcp TCO hardware or
implementation is pavailable.  Wireshark is run on this rhel5 platform over 'ssh
-X' tunnel.  The RHEL5 guest was then used to initiate the connection to the
other IPV6 system.  The direction of the connection does not matter; see below...

The Rhel4 is a paravirt install, the Debian and OpenBSD installs are full-virt.

I had also run a connection between two RHEL5 systems: one full virt and one on
bare metal; the same behaviour of non{SYN,ACK,FIN} packets have their checksums
corrupted.  This is then true for packets generated on both (RHEL5) systems. 
Let me know if you do need such a packet capture.

I double-checked TCO config on the RHEL5 FV guest: all offloading features are
disabled.
Comment 7 Marco Grigull 2008-05-25 21:23:49 EDT
FWIW I rechecked after updating to Rhel5u2.  

Kernel version Linux aurum 2.6.18-92.el5xen #1 SMP Tue Apr 29 13:31:30 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux


Non syn/ack/fin packets are still affected.
Comment 8 Marco Grigull 2008-05-27 03:49:22 EDT
The easiest way to replicate this issue:

1)confirm checsum offloading is absent
 ethtool -k lo
2) fire up wireshark (from wireshark-gnome package) to listen on lo

3) ssh ::1

no virtual machines or other machines needed..

Comment 9 Marco Grigull 2008-05-27 04:51:01 EDT
Should this ticket have been created without the 'Security Sensitive Bug' flag set?
Comment 10 Eugene Teo (Security Response) 2008-09-11 20:21:25 EDT
(In reply to comment #9)
> Should this ticket have been created without the 'Security Sensitive Bug' flag
> set?

Marco, I'm not aware of this bug, so let me go through the report first. I noticed that Wade is assigned to work on this, right? Have you spoken to any of our network developer guys about this yet?
Comment 11 Herbert Xu 2008-09-12 12:50:33 EDT
This is actually a bug in tcpdump.  Linux uses TX checksum offload on the loopback interface.  Well to be precise the TX checksum is never computed as long as the packet stays on the same host.  We export that information via AF_PACKET but tcpdump simply ignores it and instead tries to verify the partial checksum and subsequently reports it as incorrect.
Comment 12 Eugene Teo (Security Response) 2008-09-12 13:06:08 EDT
(In reply to comment #11)
> This is actually a bug in tcpdump.  Linux uses TX checksum offload on the
> loopback interface.  Well to be precise the TX checksum is never computed as
> long as the packet stays on the same host.  We export that information via
> AF_PACKET but tcpdump simply ignores it and instead tries to verify the partial
> checksum and subsequently reports it as incorrect.

Thanks for the explanation, Herbert.
Comment 13 Marco Grigull 2008-09-14 23:38:13 EDT
(In reply to comment #11)
> This is actually a bug in tcpdump.  Linux uses TX checksum offload on the
> loopback interface.  Well to be precise the TX checksum is never computed as
> long as the packet stays on the same host.  We export that information via
> AF_PACKET but tcpdump simply ignores it and instead tries to verify the partial
> checksum and subsequently reports it as incorrect.

Hi Herbert,

Which BZ is this tcpdump/libpcap bug raised in?



Regards,
Marco Grigull
Comment 14 Herbert Xu 2008-09-15 01:18:04 EDT
Hi Marco:

None that I'm aware of.  So feel free to reassign this bug over there.  Thanks!
Comment 15 Miroslav Lichvar 2008-12-17 14:07:52 EST
This will require extending libpcap API and also extending file format if the information should be preserved in files. 

It was briefly discussed on upstream list:

http://article.gmane.org/gmane.network.tcpdump.devel/2600/
Comment 16 Michal Sekletar 2011-09-29 11:13:56 EDT
This behaviour of tcpdump is known issue, for example Wireshark does not check checksum on outgoing tcp packets by default. I think there is no reason to keep this bug open in NEW if there's very little we can do about it. So I'll close this bug and set state to NOTABUG. If there's somebody who disagree please feel free to reopen it.

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