Wireshark-bugs: [Wireshark-bugs] [Bug 11058] annoying popup when trying to capture on bonds
Comment # 13
on bug 11058
from Guy Harris
(In reply to Guy Harris from comment #12)
> I'll have to spend some time looking at Linux kernel code paths to see why
> SIOCGIWMODE gets ENODEV, of all things, for those devices.
You are in a twisty little maze of code paths, all different.
It looks as if the "bonding driver", source for which is in
drivers/net/bonding, does a crap job of handling ioctls. A few ioctls are
slave-device-independent; a few others act on a slave device; the others
*should* be rejected with something such as EOPNOTSUPP or ENOTTY.
However, if the ioctl isn't one of the ones that are slave-device-independent,
the ioctl handler blithely assumes that the ifr_slave field of the ifreq
structure it's handled has been set to the name of a slave device, attempts to
fetch a handle for that slave device, and fails with ENODEV if the slave device
can't be found.
I.e., it assumes, in effect, that all the ioctls handed to it are either
slave-device-independent or one of the standard bonding device ioctls for
acting on a slave device. The ifr_slave field is a member of a union, so, for
ioctls that *aren't* one of the standard bonding device ioctls for acting on a
slave device, that field isn't present *and* its space in the structure is
taken up by some other member, so it contains random crap.
SIOCGIWMODE is an ioctl that eventually makes it to the driver's ioctl routine,
and it's most definitely not a bonding device ioctl of any sort, so....
The same, alas, is also true for SIOCGIWNAME, which is what, according to the
Wireless Extensions header file, "is used to verify the presence of Wireless
Extensions", so you can't safely verify the presence of Wireless Extensions if
the device you're using might be a bonding device.
In addition, you can't rely on /sysfs as a way of checking for wireless devices
if you want to support older kernels, so, if you want to check for monitor mode
support, you may have to use SIOCGIWNAME.
So, the right thing to do in libpcap is probably to check for bonding devices
with one of the bonding-device ioctls, if available, and don't do *anything*
that involves ioctls that could go to the device driver and might not be
supported by the device driver.
The right thing to do in dumpcap is probably to do similar checks and avoid
making libpcap calls that might do those ioctls.
You are receiving this mail because:
- You are watching all bug changes.
