Bug 132781 (IT_47489)
Summary: | [RHEL3] tcpdump not decoding NFS traffic properly on ia64 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Martin Hunt <hunt> |
Component: | tcpdump | Assignee: | Martin Stransky <stransky> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 3.0 | CC: | gharris, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | ia64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-11 08:37:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Martin Hunt
2004-09-16 22:18:48 UTC
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 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 |