is it a backwards compatability catch-22?
Subsystems (2)
I might be out to lunch, certainly it happens often enough :) I've spent the afternoon trying to stop my NIC names from being "random" on each boot. To that end, I've been doing udev rules based on an example I found at http://www.debianhelp.co.uk/udev.htm In this case I'm running a Debian 2.6.15-1 kernel.
It seems that the SYSTEM{address} looks for a case senstive match on the address (MAC) of the interface in rules like these:
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"it seems to want lower-case hex because that is what comes out of SYSFS. (?)
Of course, ifconfig -a gives HW addresses in "uppercase" hex:
lumber:~# ifconfig -a | grep HW eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2 eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3 eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71
and some of the dmesg stuff - notably e100:
lumber:~# dmesg | grep eth e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[0] eth1: dma_rwctrl[76ff2d0f] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection e100: eth3: e100_probe: addr 0x80020000, irq 57, MAC addr 00:30:6E:4C:27:3C eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3, Intr type INTA e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
While it isn't a "showstopper" it does become a bit inconvenient to have to "downshift" the MAC when taking it from ifconfig to use in the udev rules. Any chance the two can agree on one or the other? Or is each locked in a backwards compatability embrace?
rick jones
and of course, arp matches ifconfig:
lumber:~# arp -an ? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0 ? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0
not that arp in and of itself matters in this situation.
Quoted 49 lines · On Mon, 24 Apr 2006 16:47:34 -0700 Rick Jones <[email protected]> wrote:
I might be out to lunch, certainly it happens often enough :) I've spent the afternoon trying to stop my NIC names from being "random" on each boot. To that end, I've been doing udev rules based on an example I found at http://www.debianhelp.co.uk/udev.htm In this case I'm running a Debian 2.6.15-1 kernel.
It seems that the SYSTEM{address} looks for a case senstive match on the address (MAC) of the interface in rules like these:
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0" KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1" KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2" KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3" KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"it seems to want lower-case hex because that is what comes out of SYSFS. (?)
Of course, ifconfig -a gives HW addresses in "uppercase" hex:
lumber:~# ifconfig -a | grep HW eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2 eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3 eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71and some of the dmesg stuff - notably e100:
lumber:~# dmesg | grep eth e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[0] eth1: dma_rwctrl[76ff2d0f] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection e100: eth3: e100_probe: addr 0x80020000, irq 57, MAC addr 00:30:6E:4C:27:3C eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3, Intr type INTA e100: eth0: e100_watchdog: link up, 100Mbps, half-duplexWhile it isn't a "showstopper" it does become a bit inconvenient to have to "downshift" the MAC when taking it from ifconfig to use in the udev rules. Any chance the two can agree on one or the other? Or is each locked in a backwards compatability embrace?
rick jones
Quoted 7 lines
and of course, arp matches ifconfig:
lumber:~# arp -an ? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0 ? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0not that arp in and of itself matters in this situation.
Don't use the auto assigned format "eth0, eth1, eth2"?
The udev stuff runs after the device has already chosen it's default name. It has to, it's part of the hotplug infrastructure, and we don't want to depend on usermode to define the name. Just choose some other convention "eth_0" or something like that.
Signature · 2 lines
Stephen Hemminger <[email protected]> OSDL http://developer.osdl.org/~shemminger
Quoted 5 lines
The udev stuff runs after the device has already chosen it's default name. It has to, it's part of the hotplug infrastructure, and we don't want to depend on usermode to define the name. Just choose some other convention "
eth_0" or something like that.
Is that because adding another NIC at a later time might cause it to grab ethN out from under what I'm trying to do with udev?
rick jones
Quoted 10 lines · Rick Jones
Quoted 5 lines
The udev stuff runs after the device has already chosen it's default name. It has to, it's part of the hotplug infrastructure, and we don't want to depend on usermode to define the name. Just choose some other convention "
eth_0" or something like that.Is that because adding another NIC at a later time might cause it to grab ethN out from under what I'm trying to do with udev?
From what I read its likely to be because there may already be a
device named "eth1" due to default naming when you are trying to rename a device (say eth0) to eth1.
this is all because Debian now has async init, right?
BTW, since the letters in udev are all hex, it shouldn't matter whether they are upper or lower case, IMO
Jesse
Quoted 11 lines · Jesse Brandeburg
Quoted 7 lines · Rick Jones
Quoted 4 lines
The udev stuff runs after the device has already chosen it's default name. It has to, it's part of the hotplug infrastructure, and we don't want to depend on usermode to define the name. Just choose some other convention "
eth_0" or something like that.Is that because adding another NIC at a later time might cause it to grab ethN out from under what I'm trying to do with udev?
Quoted 5 lines
From what I read its likely to be because there may already be a device named "eth1" due to default naming when you are trying to rename a device (say eth0) to eth1.
this is all because Debian now has async init, right?
Beats me. I got the impression that udev things were happening "early enough" in my case that I didn't run into the issue. still, init and device names are presently a maze of twisty passages to me. someone else also suggested not using the ethN stuff - or at least not starting at 0, but start them at N where N is reasonably large. i decided to call them lan0, lan1, etc just to be perverse and see what breaks.
Quoted 2 lines
BTW, since the letters in udev are all hex, it shouldn't matter whether they are upper or lower case, IMO
that would be my opinion as well, certainly that was my expectation - that I could simply "cut and paste" MAC addresses from the likes of ifconfig output
alas, it seems that if I leave theme upper case, the renaming does not happen. i am _guessing_ the comparison is a simple string compare. and it doesn't _really_ know that what is being compared is a MAC address?
rick jones
Quoted 6 lines · Rick Jones
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"^^^
BTW, you should use "==" here instead of "=". Otherwise the rules will break with newer udev versions which behave strictly in this regard.
Michal