Bug 132781 - (IT_47489) [RHEL3] tcpdump not decoding NFS traffic properly on ia64
[RHEL3] tcpdump not decoding NFS traffic properly on ia64
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: tcpdump (Show other bugs)
3.0
ia64 Linux
low Severity medium
: ---
: ---
Assigned To: Martin Stransky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-16 18:18 EDT by Martin Hunt
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-11 04:37:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Hunt 2004-09-16 18:18:48 EDT
tcpdump doesn't decode nfs packets

For example on an ia64 machine you get:

5 [root@tdevi benroot]$ tcpdump -vvv dst -s 1024 windows
tcpdump: listening on eth0
10:04:32.337202 tdevi.799 > windows.nfs: udp 3604 (frag 47668:1480@0+)
(ttl 64, len 1500)
10:04:32.337212 tdevi > windows: udp (frag 47668:1480@1480+) (ttl 64,
len 1500)
10:04:32.337217 tdevi > windows: udp (frag 47668:652@2960) (ttl 64,
len 672)
10:04:33.594445 tdevi.799 > windows.nfs: [bad udp cksum 4172!] udp 112
(DF) (ttl 64, id 56196, len 140)
10:04:33.594692 tdevi.799 > windows.nfs: [bad udp cksum 8ec2!] udp 116
(DF) (ttl 64, id 56197, len 144)
10:04:37.337321 tdevi.799 > windows.nfs: udp 3612 (frag 47669:1480@0+)
(ttl 64, len 1500)
10:04:37.337329 tdevi > windows: udp (frag 47669:1480@1480+) (ttl 64,
len 1500)
10:04:37.337332 tdevi > windows: udp (frag 47669:660@2960) (ttl 64,
len 680)
10:04:38.208954 tdevi.800 > windows.nfs: [bad udp cksum 2cfb!] udp 116
(DF) (ttl 64, id 1067, len 144)
10:04:38.209437 tdevi.800 > windows.nfs: [bad udp cksum c80e!] udp 112
(DF) (ttl 64, id 1068, len 140)
10:04:38.209751 tdevi.800 > windows.nfs: [bad udp cksum 33a4!] udp 112
(DF) (ttl 64, id 1069, len 140)
10:04:38.210086 tdevi.800 > windows.nfs: [bad udp cksum e5a2!] udp 116
(DF) (ttl 64, id 1070, len 144)
10:04:38.210416 tdevi.800 > windows.nfs: [bad udp cksum 33a2!] udp 112
(DF) (ttl 64, id 1071, len 140)
10:04:38.210750 tdevi.800 > windows.nfs: [bad udp cksum 41c2!] udp 128
(DF) (ttl 64, id 1072, len 156)
10:04:42.138132 tdevi.799 > windows.nfs: [bad udp cksum 9edd!] udp 576
(DF) (ttl 64, id 56198, len 604)
10:04:42.138690 tdevi.799 > windows.nfs: [bad udp cksum d5a6!] udp 124
(DF) (ttl 64, id 56199, len 152)
10:04:42.337404 tdevi.799 > windows.nfs: udp 3468 (frag 47670:1480@0+)
(ttl 64, len 1500)
10:04:42.337413 tdevi > windows: udp (frag 47670:1480@1480+) (ttl 64,
len 1500)
10:04:42.337417 tdevi > windows: udp (frag 47670:516@2960) (ttl 64,
len 536)
10:04:42.337434 tdevi.799 > windows.nfs: [bad udp cksum 5cd2!] udp 272
(DF) (ttl 64, id 56200, len 300)

but on ia32 you get:

3 [ben@toad2 ben]$sudo tcpdump -vvv dst -s 1024 windows
tcpdump: listening on eip0
10:07:11.777350 toad2.3882793533 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 16074, len 144)
10:07:11.777747 toad2.3899570749 > windows.nfs: 132 lookup fh
Unknown/1 "dircolors" (DF) (ttl 64, id 16075, len 160)
10:07:11.780860 toad2.3916347965 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 15065, len 144)
10:07:11.782182 toad2.3933125181 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 16076, len 144)
10:07:11.782480 toad2.3949902397 > windows.nfs: 128 lookup fh
Unknown/1 "egrep" (DF) (ttl 64, id 16077, len 156)
10:07:11.786259 toad2.3966679613 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 16078, len 144)
10:07:11.786653 toad2.3983456829 > windows.nfs: 124 lookup fh
Unknown/1 "grep" (DF) (ttl 64, id 16079, len 152)
10:07:11.786950 toad2.4000234045 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 16080, len 144)
10:07:11.787199 toad2.4017011261 > windows.nfs: 124 lookup fh
Unknown/1 "grep" (DF) (ttl 64, id 16081, len 152)
10:07:11.807175 toad2.4033788477 > windows.nfs: 116 getattr fh
Unknown/1 (DF) (ttl 64, id 15066, len 144)
10:07:11.807624 toad2.4050565693 > windows.nfs: 128 lookup fh
Unknown/1 ".i18n" (DF) (ttl 64, id 15067, len 156)

----------
Action by: woodard
Issue Registered
Comment 1 Martin Hunt 2004-09-16 18:21:04 EDT
In function udp_print, everything is fine until this:
rp = (struct rpc_msg *)(up + 1);

You just cannot do that.  The code is assuming that the bits on the
wire are identical to the struct rpc_msg declared in
/usr/include/rpc/rpc_msg.h.  For one thing, those u_longs in the
struct are 32 bits on IA32 and 64 bits in IA64. So everything
is broken past this point.  There are other places in tcpdump that are
similarly broken, even on x86.

A good workaround is to use tethereal, which works fine on IA64.

Comment 6 Guy Harris 2005-04-13 04:30:23 EDT
The current top-of-tree CVS for tcpdump at tcpdump.org, and the 3.9 branch of tcpdump, have their 
own rpc_msg.h headers, which do not use "long" anywhere.

I've fixed a problem where u_long was being used in the SCTP dissector where it wouldn't work in an 
LP64 environment (BTW, IA-64 is not the biggest LP64 environment - that's probably x86-64, and 
there were plenty of LP64 environments in UN*X in general, including Linux, before IA-64, so these 
issues aren't IA-64 issues, they're generic LP64 issues).

There don't appear to be any other such issues in the top-of-tree CVS of tcpdump, or in the 3.9 
branch.  Please check those branches to make sure that the "other places in tcpdump that are similarly 
broken" are fixed, as we'd like to put out a 3.9 release soon, and would prefer that it not have any LP64 
bugs.
Comment 7 Martin Stransky 2005-04-21 09:47:10 EDT
The "bad udp cksum" problem is still alive in 3.9 version, so I'll
explore where the problem is.
Comment 8 Martin Hunt 2005-04-21 13:01:27 EDT
tcpdump complaining about bad checksums is actually normal behavior on
a machine that is offloading checksum calculation to the ethernet card.
tcpdump is grabbing the packets before they hit the ethernet card, so
the checksum hasn't been computed.

To check if your card is offloading checksum calculations, do
# /sbin/ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off

You can temporarily disable tx checksums and try again.  The bad
chksum messages should disappear.
# /sbin/ethtool -K eth0 tx off
Comment 9 Guy Harris 2005-04-22 01:49:55 EDT
Yes.  The "bad udp cksum" issue is unrelated to the NFS decode issue; the Internet 
checksum routine doesn't use "long" or "unsigned long", so it wouldn't be affected by 
ILP32 vs. LP64, and, if your interface is doing checksum offloading, outgoing packets 
(packets sent by the machine running tcpdump - or running Tethereal or running Ethereal 
or running any *other* network analyzer that checks IP/TCP/UDP checksums) using a 
protocol whose checksum is offloaded won't have a valid checksum when captured by the 
network analyzer in question.
Comment 10 Martin Stransky 2005-04-22 05:30:46 EDT
Ahh, thanks for explanation, in this case 3.9 looks good...
Comment 11 Mark J. Cox (Product Security) 2005-05-11 04:38:01 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-421.html
Comment 12 Mark J. Cox (Product Security) 2005-05-11 04:53:39 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-421.html

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