This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 435131 - Xenner does not detect TAP device correctly, sometimes picking the bridge
Xenner does not detect TAP device correctly, sometimes picking the bridge
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xenner (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Gerd Hoffmann
Fedora Extras Quality Assurance
:
Depends On:
Blocks: LibvirtXenner
  Show dependency treegraph
 
Reported: 2008-02-27 11:07 EST by Daniel Berrange
Modified: 2008-02-27 16:37 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-27 16:37:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Change logic for detecting tap devices (1.22 KB, patch)
2008-02-27 11:09 EST, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2008-02-27 11:07:15 EST
Description of problem:
The tap_fd_to_name() method in xenner.c iterates over 65535 interface indexes
querying each one for its mac address. It compares against the expected mac
address for the TAP fd forwarded from libvirtd. The logic assumes that the TAP
device interface index will always be greater than the bridge device interface
index because the bridge device may have the same MAC too.

Unfortunately this assumption does not appear to hold true on my test system
where the bridge device is after the TAP device

24273 ioctl(5, SIOCGIFNAME, {ifr_index=27, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=28, ifr_name="vnet0"}) = 0
24273 ioctl(5, SIOCGIFHWADDR, {ifr_name="vnet0", ifr_hwaddr=00:16:3e:58:eb:6f}) = 0
24273 ioctl(5, SIOCGIFNAME, {ifr_index=29, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=30, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=31, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=32, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=33, ifr_name="virbr0"}) = 0
24273 ioctl(5, SIOCGIFHWADDR, {ifr_name="virbr0", ifr_hwaddr=00:16:3e:58:eb:6f}) = 0
24273 ioctl(5, SIOCGIFNAME, {ifr_index=34, ifr_name=???}) = -1 ENODEV (No such
device)
24273 ioctl(5, SIOCGIFNAME, {ifr_index=35, ifr_name=???}) = -1 ENODEV (No such
device)


So, Xenner tries to then invoke a TUNSETPERSIST ioctl() on the bridge device &
fails.

Since we can't assume anything about interface ordering, Xenner needs a
different approach to distinguish a TAP device from a bridge device. One option
is to simply try TUNSETPERSIST on each interface with a matching MAC address. If
you get '-EINVAL' from the ioctl() then it indicates the interface is not a TAP
device & should be skipped.

Version-Release number of selected component (if applicable):
xenner-0.23 and xenner-0.25

How reproducible:
Sometimes

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Daniel Berrange 2008-02-27 11:09:29 EST
Created attachment 296084 [details]
Change logic for detecting tap devices

This patch implements the idea suggested above
Comment 2 Daniel Berrange 2008-02-27 16:37:25 EST
I have built this patch into xenner-0.25-4.fc9

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