Bug 435131 - Xenner does not detect TAP device correctly, sometimes picking the bridge
Summary: Xenner does not detect TAP device correctly, sometimes picking the bridge
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xenner
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Gerd Hoffmann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: LibvirtXenner
TreeView+ depends on / blocked
 
Reported: 2008-02-27 16:07 UTC by Daniel Berrangé
Modified: 2008-02-27 21:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-27 21:37:25 UTC
Type: ---
Embargoed:


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

Description Daniel Berrangé 2008-02-27 16:07:15 UTC
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 Berrangé 2008-02-27 16:09:29 UTC
Created attachment 296084 [details]
Change logic for detecting tap devices

This patch implements the idea suggested above

Comment 2 Daniel Berrangé 2008-02-27 21:37:25 UTC
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.