|
Red Hat Bugzilla – Full Text Bug Listing |
| Summary: | Xenner does not detect TAP device correctly, sometimes picking the bridge | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Berrange <berrange> | ||||
| Component: | xenner | Assignee: | Gerd Hoffmann <kraxel> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | 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: | |||||
| Cloudforms Team: | --- | ||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 435059 | ||||||
| Attachments: |
|
||||||
Created attachment 296084 [details]
Change logic for detecting tap devices
This patch implements the idea suggested above
I have built this patch into xenner-0.25-4.fc9 |
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: