is it a backwards compatability catch-22?

is it a backwards compatability catch-22?

[Rick Jones]

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.

Re: is it a backwards compatability catch-22?

[Stephen Hemminger]

On Mon, 24 Apr 2006 16:47:34 -0700
Rick Jones <rick.jones2@hp.com> 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: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.

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.



-- 
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger

Re: is it a backwards compatability catch-22?

[Rick Jones]

> 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

Re: is it a backwards compatability catch-22?

[Jesse Brandeburg]

On 4/24/06, Rick Jones <rick.jones2@hp.com> wrote:
>
> > 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

Re: is it a backwards compatability catch-22?

[Rick Jones]

Jesse Brandeburg wrote:
> On 4/24/06, Rick Jones <rick.jones2@hp.com> wrote:
> 
>>>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?

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.

> 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

Re: is it a backwards compatability catch-22?

[Michal Schmidt]

Rick Jones wrote:
> 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