Ubuntu

udev rule can fail to run ifdown, break reinserting device

Reported by Brian Brunswick on 2007-08-04
46
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Undecided
Unassigned
Nominated for Hardy by Brian Brunswick

Bug Description

Binary package hint: ifupdown

Package: ifupdown
Version: 0.6.8ubuntu6
Severity: normal
Tags: patch

In the /etc/udev/rules.d/85-ifupdown.rules, the remove
rule is, like the add one, conditionalised under
SUBSYSTEM=="net" and DRIVERS=="?*". Unfortunately,
on my system (cdc usb ether driver, connecting to openmoko phone)
the DRIVERS variable isn't set at all when the device is unplugged.

This causes ifdown to fail to be run on device removal, which prevents
the device working next time it is plugged in, since ifup doesn't
do anything when the interface is already up.

Fix: Move the remove line to the end of the file, and insert conditional
subsystem.

SUBSYSTEM=="net", ACTION=="remove", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}"

-- System Information:
Debian Release: 4.0
  APT prefers feisty-security
  APT policy: (500, 'feisty-security'), (500, 'feisty')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.20-16-generic
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages ifupdown depends on:
ii cdebconf [debconf-2.0] 0.111ubuntu2 Debian Configuration Management Sy
ii debconf [debconf-2.0] 1.5.13ubuntu1 Debian configuration management sy
ii libc6 2.5-0ubuntu14 GNU C Library: Shared libraries
ii lsb-base 3.1-22ubuntu3 Linux Standard Base 3.1 init scrip
ii net-tools 1.60-17ubuntu1 The NET-3 networking toolkit

ifupdown recommends no packages.

-- debconf information:
  ifupdown/convert-interfaces: true
  ifupdown/convert-interfaces-hotplug: true

Related branches

Alan Jenkins (aj504) wrote :

I can confirm this on my hardware, a Netgear WG111v2, using the rtl8187 driver.

My workaround was just to remove "DRIVERS=?*", since I didn't see how a network device could appear without a driver anyway. I'd say the real bug is either in udev or the kernel not providing this information.

An obvious reason to be interested in the driver would be to remove the kernel module when the last device supported by it is removed.

Rémi Denis-Courmont (rdenis) wrote :

Same problem here. Moving the DRIVERS=="*?" out of the top GOTO, to ACTION=="add" line fixes the problem. Though adding --auto to ifupdown at ACTION=="add" might improve reliability (?).

Ashish SHUKLA (wahjava) wrote :

I can also confirm this bug on Gutsy (amd64).

Brian Brunswick (brian-ithil) wrote :

Just had a look and in the hardy alpha it seems unchanged.

How about some bug love people!

Young-Ho Cha (ganadist-gmail) wrote :

Hardy beta was released. but it wasn't applied yet. :(

Brad Midgley (bmidgley-gmail) wrote :

A newer suggestion on the openmoko wiki is to move the label net_end to be above the remove action. The resulting /etc/udev/rules.d/85-ifupdown.rules looks like:

SUBSYSTEM=="net", DRIVERS=="?*", GOTO="net_start"
GOTO="net_end"

LABEL="net_start"
ACTION=="add", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}"

LABEL="net_end"
ACTION=="remove", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifdown -- --allow auto $env{INTERFACE}"

I confirm seeing this on an uptodate Hardy. The attached fix works.

Changed in ifupdown:
status: New → Confirmed
Tormod Volden (tormodvolden) wrote :

As I explained in https://bugs.edge.launchpad.net/ubuntu/+source/dhcp3/+bug/38140/comments/15, the fix in comment 7 here is wrong.

Removing the DRIVERS== clause would be better, but it adds some value: it matches real devices with hardware drivers, and not virtual net devices like "lo".

Alistair Buxton (a-j-buxton) wrote :

Neither of the fixes works properly on Ibex. Both cause routing and /etc/resolv.conf to get trashed with incorrect values from usb0 which has neither a default gateway nor DNS servers defined. The end result is two default routes in the routing table with the usb0 route having higher priority than the eth0 route, a blank /etc/resolv.conf, and no internet connectivity.

Note that without the above fixes this situation does not occur, but as before, the device can only be plugged in once time.

The fix worked properly for me on Hardy.

a1bert (a1bert) wrote :

the same problem with bluetooth PAN, after client disconecting, bnep0 net remove event reaches 85-ifupdown.rules without DRIVER set. fixed with:

SUBSYSTEM=="net", KERNEL=="bnep?*", GOTO="net_start"

SUBSYSTEM=="net", DRIVERS=="?*", GOTO="net_start"
GOTO="net_end"

...
...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ifupdown - 0.6.8ubuntu18

---------------
ifupdown (0.6.8ubuntu18) jaunty; urgency=low

  * debian/ifupdown.udev: Unconditionally call ifdown when the network
    interface is removed, instead of checking DRIVERS which is likely gone
    anyway. LP: #130437.
  * Clean up the mess of the rules file while I was in there ;)

 -- Scott James Remnant <email address hidden> Thu, 05 Mar 2009 14:11:42 +0000

Changed in ifupdown:
status: Confirmed → Fix Released
Valentin Longchamp (longfield) wrote :

I can confirm that this is fixed with jaunty, usb networking now works fine with ifupdown udev script in jaunty.

Roberto Gordo Saez (rgs) wrote :

It looks broken again since I've upgraded to Karmic.
ifupdown 0.6.8ubuntu20 changelog says: Replace the udev rule with a per-interface Upstart job.
Works again if I put the old udev rule file in /etc/udev/rules.d

yeah I just found out Karmic has a typo in /etc/init/network-interface.conf

stop on net-device-removed INTERFACE=$INTERFACE

should be

stop on net-device-remove INTERFACE=$INTERFACE

Furthermore, the DRIVERS var is not filled when the device gets plugged (add action), resulting in an infinite amount of entries in /etc/udev/rules.d/70-persistent-net.rules (because the device doesn't match the dynamically generated rule there)

yeah I just found out Karmic has a typo in /etc/init/network-interface.conf

stop on net-device-removed INTERFACE=$INTERFACE

should be

stop on net-device-remove INTERFACE=$INTERFACE

Furthermore, the DRIVERS var is not filled when the device gets plugged (add action), resulting in an infinite amount of entries in /etc/udev/rules.d/70-persistent-net.rules (because the device doesn't match the dynamically generated rule there)

Changed in ifupdown (Ubuntu):
status: Fix Released → Confirmed

hmm and now I cannot reproduce anymore :-Z
must be lack of coffee..

Changed in ifupdown (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers