FS#25189 - [udev] vlan interfaces get renamed by udev

Attached to Project: Arch Linux
Opened by Dominik (Dominik) - Wednesday, 20 July 2011, 13:59 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 26 July 2011, 11:06 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Tom Gundersen (tomegun)
Architecture x86_64
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I renamed the ethernet interface of my notebook by a udev rule:

/etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ATTR{address}=="00:1c:22:b3:41:2c", NAME="lan0"

If I try to add a interface for VLAN 10 I didn't get the expected lan0.10 interface.

# ip link add link lan0 name lan0.10 type vlan id 10

I get an interface with the name rename46@lan0. If I disable the udev rule and having
a eth0 interface I get eth0.10@eth0 as interface.

Functionality with the rename46@lan0 interface isn't broken so I can us it for VLAN 10 but
if you have more VLAN interfaces you need to have a look at /proc/net/vlan/<INTERAFCENAME>
to see which VLAN is configured.

I have udev 171-2 (base) and iproute2 2.6.38-4 installed on a x86_64 system.

I expect that if I create a vlan on an interface that it has the name that I configre with
ip.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 26 July 2011, 11:06 GMT
Reason for closing:  Fixed
Comment by Tom Gundersen (tomegun) - Thursday, 21 July 2011, 15:22 GMT
Possibly related: <https://bugzilla.redhat.com/show_bug.cgi?id=723936>
Comment by Tom Gundersen (tomegun) - Thursday, 21 July 2011, 15:40 GMT
Kay Sievers suggests that the problem is that your udev rule is too broad. If your box has several devices with the same mac this will cause havoc. Check out what mac addresses your NIC's have to see if this is the problem, and if so, try to make a more specific rule.
Comment by Dominik (Dominik) - Thursday, 21 July 2011, 17:06 GMT
Good idea. Thank you for the information. I'll give it a try to be more specific at the rule. First I need to learn much more about udev. It is very powerfull.

# udevadm info -a -p /sys/class/net/lan0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:19.0/net/lan0':
KERNEL=="lan0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_assign_type}=="0"
ATTR{addr_len}=="6"
ATTR{dev_id}=="0x0"
ATTR{ifalias}==""
ATTR{iflink}=="2"
ATTR{ifindex}=="2"
ATTR{features}=="0x1149a9"
ATTR{type}=="1"
ATTR{link_mode}=="0"
ATTR{address}=="00:1c:25:a1:14:07"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="0"
ATTR{speed}=="65535"
ATTR{duplex}=="full"
ATTR{dormant}=="0"
ATTR{operstate}=="down"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="1000"
ATTR{netdev_group}=="0"

looking at parent device '/devices/pci0000:00/0000:00:19.0':
KERNELS=="0000:00:19.0"
SUBSYSTEMS=="pci"
DRIVERS=="e1000e"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x10f5"
ATTRS{subsystem_vendor}=="0x17aa"
ATTRS{subsystem_device}=="0x20ee"
ATTRS{class}=="0x020000"
ATTRS{irq}=="45"
ATTRS{local_cpus}=="00000000,00000003"
ATTRS{local_cpulist}=="0-1"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="64"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{enable}=="4294967291"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
Comment by Tom Gundersen (tomegun) - Monday, 25 July 2011, 14:52 GMT
I would boot without the rule, and then do
# udevadm info -a -p /sys/class/net/<$nic>

For each of the nics you have. Then you can compare the info to find what is required to distinguish them from each other and create a good rule.

Please report back whether or not this solves the problem.
Comment by Dominik (Dominik) - Tuesday, 26 July 2011, 09:39 GMT
Ok I get it solved with a mor specific udev rule:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1c:25:a1:14:07", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="lan0"

Now if I do

~]# ip link add link lan0 name lan0.10 type vlan id 10

I get the correct vlan device name.

lan0.10@lan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether 00:1c:25:a1:14:07 brd ff:ff:ff:ff:ff:ff

Thank you for helping and sorry that I thought it was a bug. Archlinux is so wonderfull!

The request could be closed.
Comment by Tom Gundersen (tomegun) - Tuesday, 26 July 2011, 11:06 GMT
No problem. I learnt a lot figuring it out ;)

Loading...