add action uses wrong interface name in 85-ifupdown.rules

[Jürgen Kreileder]

When network interfaces get renamed via 25-iftab.rules and /etc/iftab, the add action in 85-ifupdown.rules uses the wrong interface name.

In the attached log, 'eth0' gets renamed to 'wifi', but ifup gets called for 'eth0' instead of 'wifi'.

[Jürgen Kreileder (jk)]

udev debug log

[Jürgen Kreileder (jk)]

I'm using this work-around for now but I wonder why the rule doesn't see the correct INTERFACE value (the setenv in udev_add.c seems to be OK).

[Scott James Remnant (Canonical) (canonical-scott)]

Definitely a major bug, however I'm sure this would have appeared earlier if it was breaking for everyone. Will test it here to see whether I can confirm.

[Jürgen Kreileder (jk)]

udevmonitor shows that INTERFACE indeed gets set correctly but the rule nevertheless gets the wrong value:

UEVENT[1144694030.924086] add@/class/net/eth0
ACTION=add
DEVPATH=/class/net/eth0
SUBSYSTEM=net
SEQNUM=933
PHYSDEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:03:03.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ipw2200
INTERFACE=eth0

UDEV [1144694030.937425] add@/class/net/eth0
UDEV_LOG=7
ACTION=add
DEVPATH=/class/net/wifi
SUBSYSTEM=net
SEQNUM=933
PHYSDEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:03:03.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ipw2200
INTERFACE=wifi
UDEVD_EVENT=1

[Scott James Remnant (Canonical) (canonical-scott)]

I can confirm this here, debugging now.

[Scott James Remnant (Canonical) (canonical-scott)]

Key points from debug log (which isn't the same as what you attached above, which was just an info log)

apply_format: will substitute format name 'env'
get_format_attribute: attribute='INTERFACE', str=''
apply_format: format=14, string='/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto ', tail='',
class_dev=0x80631d0, sysfs_dev=0x8064c10
apply_format: substitute env 'INTERFACE=eth0'
udev_rules_get_name: add run '/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto eth0'
name_list_add: adding '/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto eth0'
udev_rules_iter_next: current=289188

So getenv("INTERFACE") is definitely returning "eth0" at that point.

[Scott James Remnant (Canonical) (canonical-scott)]

And I've checked the renaming code, getenv("INTERFACE") definitely returns "test" at that point!

The problem appears to be that the value in the rule is expanded before the interface is actually renamed.

[Jürgen Kreileder (jk)]

The reason why this doen't bite many people is that 85-ifupdown.rules just tries to bring up interfaces which are marked 'auto', those are if-uped by /etc/init.d/networking anyhow.

I was trying to use a similar rule for starting ifplugd when I noticed this problem (no 'auto' interfaces).

[Scott James Remnant (Canonical) (canonical-scott)]

Aha!

And this finally explains the strange symptoms where an interface sometimes would get brought up by "ifup -a" when it should have been brought up by udev.

Excellent.

The bug is simply that the NAME bit of the rule is applied after the run list has been created; the easiest solution to this is implementing a $name expansion that doesn't rely on the environment being modified.

udev fix being uploaded now, ifupdown in a few minutes time.

[Scott James Remnant (Canonical) (canonical-scott)]

Actually, I just realised the fix isn't that simple as we need to deal with enumeration of devices.

I'll have to find a way to delay the format application until after the NAME rule has been applied.

[Scott James Remnant (Canonical) (canonical-scott)]

This was fixed in upstream, but after they reworked udevd to remove libsysfs; I've rewritten that patch and it seems to fix the problem here.

[Scott James Remnant (Canonical) (canonical-scott)]

Uploaded to dapper, please try 0ubuntu25

[Scott James Remnant (Canonical) (canonical-scott)]

Note that no ifupdown change is needed with the udev patch I've uploaded.