Bug 435131

Summary: Xenner does not detect TAP device correctly, sometimes picking the bridge
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: xennerAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: berrange
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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:
Bug Depends On:    
Bug Blocks: 435059    
Attachments:
Description Flags
Change logic for detecting tap devices none

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