Bug 314551 - udev incorrectly renames a network interface
udev incorrectly renames a network interface
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
7
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Eduardo Habkost
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-01 15:16 EDT by Ashish Shukla
Modified: 2009-12-14 15:41 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-09 17:32:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (22.17 KB, text/plain)
2007-10-01 15:16 EDT, Ashish Shukla
no flags Details
Output of commands before power-cycling modem (11.99 KB, application/x-gzip)
2007-10-09 15:53 EDT, Ashish Shukla
no flags Details
Output of commands after power-cycling modem (11.97 KB, application/x-gzip)
2007-10-09 15:53 EDT, Ashish Shukla
no flags Details

  None (edit)
Description Ashish Shukla 2007-10-01 15:16:47 EDT
Description of problem:
I've 3 physical network interfaces (1 PCI NIC rtl8159 - eth0, 1 Onboard NIC e100
- eth1, and 1 USB NIC cdc-ether - eth2). All 3 physical interfaces work fine
(and initialized to their default names) when running default 'kernel'. In
'kernel-xen' (running as domain 0) at startup all NICs are initialized to their
default names, but when 'eth2' is disconnected and reconnected, it gets detected
as 'eth3', whereas 'eth2' used to be still present, but MAC address changed to
'00:00:00:00:00:00'.

Version-Release number of selected component (if applicable):
kernel-xen-2.6.20-2936.fc7
udev-113-12.fc7


How reproducible:
Reproducible everytime.

Steps to Reproduce:
1. Turn off the ADSL modem (to which eth2 is connected).
2. Turn on the ADSL modem, now eth3 will appear, but eth2's MAC address gets
changed to "00:00:00:00:00:00".

  
Actual results:
The 'eth2' interface now gets detected as 'eth3' whereas 'eth2' is still present.

Expected results:
'eth2' should be always detected as 'eth2'.

Additional info:
The 'dmesg' output is attached.
Comment 1 Ashish Shukla 2007-10-01 15:16:47 EDT
Created attachment 212711 [details]
dmesg output
Comment 2 Daniel Berrange 2007-10-09 11:20:54 EDT
Please provide output of

  - 'ifconfig -a'
  - 'brctl show'
  - 'lshal'

Please capture the data both before and after  unplugging & reconnecting the
ADSL modem.
Comment 3 Ashish Shukla 2007-10-09 15:53:27 EDT
Created attachment 221711 [details]
Output of commands before power-cycling modem
Comment 4 Ashish Shukla 2007-10-09 15:53:52 EDT
Created attachment 221721 [details]
Output of commands after power-cycling modem
Comment 5 Daniel Berrange 2007-10-09 17:32:11 EDT
Ok, so the problem is thus:

  - When booting the kernel-xen, XenD will start (/etc/init.d/xend script)
  - XenD by default attempts to place your primary active NIC into a bridge at
boot time
  - You have 3 nics, eth0, eth1, and eth2. It looks like eth2 is the only active
NIC. Therefore XenD puts eth2 into a bridge
  - When eth2 is enslaved, it gets renamed to peth2, and 'eth2' becomes the
bridge device
  - When you turn off the modem, the physical device, peth2,  goes away. The
bridge, eth2, stays around.
  - When you turn it back on,  eth2 (the bridge) is still there, so your modem
gets eth3.

The core issue here is that XenD's bridging setup assumes that your primary NIC
never goes away. There is no way to fix it work with dynamic devices which come
& go, so the best option is to turn it off, or ensure that another permanently
connected device is always active at boot.

To turn it off, edit /etc/xen/xend-config.sxp and find the line refering to

 (network-script network-bridge)

And change it to

 (network-script /bin/true)

This will ensure that your ADSL modem device, or any other device, is never
bridged by XenD at boot time.

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