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
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.
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.
The "bad udp cksum" problem is still alive in 3.9 version, so I'll explore where the problem is.
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
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.
Ahh, thanks for explanation, in this case 3.9 looks good...
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