Bug 180980 - tcpdump -i ib0 not working with OpenIB IPoIb
tcpdump -i ib0 not working with OpenIB IPoIb
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
Brian Brock
:
: 180981 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-10 17:28 EST by Scott Weitzenkamp
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-07 20:33:54 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)
Actual change from mainline (705 bytes, patch)
2006-02-26 22:54 EST, Roland Dreier
no flags Details | Diff

  None (edit)
Description Scott Weitzenkamp 2006-02-10 17:28:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Description of problem:
I am using 2.6.9-27 x86_64 and ia64 kernels, testing OpenIB.  IPoIB is working in general, but tcpdump does not work with IPoIB.

# tcpdump -i ib0
tcpdump: ioctl: Value too large for defined data type

strace says:

ioctl(3, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0
ioctl(3, SIOCGIFHWADDR, {ifr_name="ib0", ???}) = -1 EOVERFLOW (Value too large f
or defined data type)
close(3)                                = 0
write(2, "tcpdump: ", 9tcpdump: )                = 9
write(2, "ioctl: Value too large for defin"..., 44ioctl: Value too large for def
ined data type) = 44


Version-Release number of selected component (if applicable):
tcpdump-3.8.2-9.RHEL4

How reproducible:
Always

Steps to Reproduce:
1. modprobe ib_ipoib
2. tcpdump -i ib0
3.
  

Actual Results:  command failed

Expected Results:  packet dump

Additional info:

none
Comment 1 Scott Weitzenkamp 2006-02-10 17:30:27 EST
*** Bug 180981 has been marked as a duplicate of this bug. ***
Comment 2 Martin Stransky 2006-02-20 12:03:01 EST
I'll check it as soon as I have some IB device handy...
Comment 3 Roland Dreier 2006-02-26 22:52:40 EST
I think the problem is the RHEL4-specific change
linux-2.6.9-net-SIOCGIFHWADDR-NULL-dev_addr.patch, which is included because of
bug 137648.  The patch changes the SIOCGIFHWADDR ioctl to return EOVERFLOW if
the net device's HW address length is more than the sizeof the structure it's
copying to.  Unfortunately struct sockaddr can only hold 14 bytes, and IPoIB net
devices have a 20 byte HW address, so the ioctl can't be used to get the HW
address of an IPoIB interface.  The test and EOVERFLOW return are not in the
upstream kernel.

The simplest fix is to remove the EOVERFLOW return from the patch you use. 
Since the EOVERFLOW return is not upstream and breaks an important diagnostic
tool, I don't think there's any reason to keep it.  (I don't think you want to
try and change tcpdump to use rtnetlink ;)
Comment 4 Roland Dreier 2006-02-26 22:54:31 EST
Created attachment 125302 [details]
Actual change from mainline

Here's the actual patch from Matt Domsch that went into mainline.  This is
slightly different than the patch in bug 137648, and in particular does not
include the EOVERFLOW return.  It might make sense to replace your patch with
this so you can match upstream more closely.
Comment 5 Martin Stransky 2006-02-27 08:57:26 EST
okay, reassigning to kernel guys...
Comment 6 Doug Ledford 2006-02-27 13:22:50 EST
This is an area where I disagree with upstream.  If you can't get the data into
the data size allowed, and you don't return an error, then you get applications
silently using the wrong data.  I would much rather know that tcpdump is getting
bad data so I know to fix it than have to deal with it silently using chopped
off data and people then asking why tcpdump shows truncated values or duplicate
values.  So, even if upstream decides to take the easy way out and let tcpdump
use bad data, I'm not sure that's appropriate for our distribution given that we
have support requirements that upstream does not.
Comment 7 Roland Dreier 2006-02-27 16:07:07 EST
If you want the SIOCGIFHWADDR ioctl to be able to return EOVERFLOW, then
I guess you need to patch tcpdump to continue after the ioctl fails.  Clearly
having tcpdump that refuses to work is the biggest support problem of all.

I think the change you need to make is in pcap-linux.c in iface_get_arptype().
Note that the EOVERFLOW test in the kernel prevents the SIOCGIFHWADDR ioctl
from setting the sa_family field, so even though tcpdump doesn't even look at
the HW address (only the sa_family field), it has a problem here.
Comment 8 Scott Weitzenkamp 2006-04-11 16:17:40 EDT
Any chance of getting a working tcpdump soon?
Comment 9 Scott Weitzenkamp 2006-05-10 12:18:21 EDT
Any progress on this bug?
Comment 10 Lonni J Friedman 2006-06-14 11:17:07 EDT
This bug is hitting me too.  Is there any chance that this is going to be
resolved in the near future?
Comment 11 Doug Ledford 2006-08-28 19:20:07 EDT
This is slated to be fixed in RHEL4.5.
Comment 12 Guy Harris 2006-09-19 02:35:20 EDT
Note that the ioctl does *NOT* supply the length of the data structure being filled in; the EOVERFLOW 
check:

			if ((size_t) dev->addr_len > sizeof ifr->ifr_hwaddr.sa_data)
				return -EOVERFLOW;

checks against the size of the "sa_data" member of "ifr->ifr_hwaddr", which is a "struct sockaddr", so 
the size is a hard-wired 14 bytes.  Thus, if "dev->addr_len" for a device is greater than 14, *NOTHING* 
can make an SIOCGIFHWADDR ioctl succeed on the device, and thus, as SIOCGIFHWADDR appears to be 
the only way to get "dev->type", *NOTHING* can allow the ARPHRD_ value for that device to be fetched 
from userland.

Thus, to allow tcpdump (or Wireshark, or anything *else* that uses libpcap) to work on Infiniband 
interfaces, you will have to provide some other way of getting the ARPHRD_ value for the device (so 
libpcap determine the link-layer type and supply it to its callers; unfortunately, that would leave no way 
for code that *does* need the link-layer address no way to get it for interfaces such as Infiniband 
interfaces with too-long link-layer addresses), or you will have to change the ifru_hwaddr member of 
the union inside "struct ifreq" to a "struct sockaddr_ll" (which would run the risk of breaking source 
compatibility - *AND* means that an ioctl call compiled with the old structure could cause stuff after 
the structure to be scribbled on), or you could do that but have SIOCGIFHWADDR check against the old 
length and add a new ioctl that checks against the new length (that, at least, means old code will fail 
with EOVERFLOW rather than scribbling on data past the end of the structure), or provide a new ioctl 
where the length is specified as part of the argument (which means that the right checking can be 
done, at least).

The most I could do in libpcap is, if the SIOCGIFHWADDR ioctl fails with EOVERFLOW, just punt and do a 
"cooked" capture.  That currently means no promiscuous mode, and only "cooked" headers.
Comment 13 Guy Harris 2006-09-19 03:31:20 EDT
One possibility - add a "struct sockaddr_ll" to the  union as a new member, and then have the old ioctl 
codes use the old structure and allocate new ioctl codes for the new structure in cases where it matters.

Or, alternatively, do it with a procfs/sysfs/whatever device rather than an ioctl, as ioctl is, to some extent, 
broken by design.
Comment 14 Roland Dreier 2006-09-19 11:52:54 EDT
(replying to Guy's comments)

First, let's be clear that this EOVERFLOW check is only in RHEL kernels and not
in the standard upstream kernel, so there's no reason to work around this
misfeature in libpcap.  I believe Red Hat is already planning to fix the kernel
for the next RHEL4 update.

Second, there already is a Linux mechanism for userspace to get information
about interfaces with long hardware addresses: rtnetlink.  For example, the "ip"
command from iprouteutils uses rtnetlink, and "ip addr" shows the link type and
full 20-byte hardware adress of IPoIB devices with no problem:

    # ip addr show dev ib0
    5: ib0: <BROADCAST,MULTICAST> mtu 2044 qdisc noop qlen 128
        link/infiniband
00:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:21:70:d1 brd
00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
Comment 15 Doug Ledford 2006-11-01 17:25:29 EST
The upstream version of the patch has been submitted as a replacement for the
one currently in the RHEL4 kernels.
Comment 16 Jason Baron 2006-11-03 17:04:35 EST
committed in stream U5 build 42.23. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 17 RHEL Product and Program Management 2006-11-27 22:36:24 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 18 RHEL Product and Program Management 2006-11-27 22:37:13 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 19 RHEL Product and Program Management 2006-11-27 22:37:48 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 20 RHEL Product and Program Management 2006-11-27 22:37:48 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 21 Jay Turner 2006-12-18 09:25:22 EST
QE ack for RHEL4.5.
Comment 24 Red Hat Bugzilla 2007-05-07 20:33:54 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/RHBA-2007-0304.html

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