udev stops pppd persist working

[Alan]

Binary package hint: udev

Product: Ubuntu Server
Version: 6.10
Component:udev
Severity: High
Priority: High
URL: http://rants.atmurray.net/2007/01/pppd-persist-not-so-persist-with-udev.html
Summary: udev stops pppd persist working
Description:
When a pppd session is disconnected it triggers the udev script /etc/udev/rules.d/85-ifupdown.rules to ifdown the ppp link which kills pppd and stopping a reconnection.

Steps to Reproduce:
1) Create a persistent ppp connection and have it set to auto in /etc/network/interfaces
2) Cause it to disconnect

Actual Results: udev runs ifdown on the interface causing pppd to be sent the TERM signal
Expected Results: As it is a ppp link udev should not touch it.
Additional Builds and Platforms:
I believe this bug occurred and was fixed when hutplug was implemented.
SUSE linux has fixed this bug by explicitly skipping the udev actions for some link types

Additional Information:
I suggest the following two lines in /etc/udev/rules.d/85-ifupdown.rules be changed accordingly:

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

and then allow-hotplug be added to /etc/network/interfaces for interfaces to be controlled by udev.

[Ricardo Correia (wizeman)]

I confirm the bug in Ubuntu Dapper, this should be fixed..

It is a very frustrating bug since it almost seemed like pppd was ignoring the "persist" option and leaving me without Internet access every 36 hours (ISP resets)..

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

Fixed rules to only take affect for devices with drivers

[Roshan Shariff (roshan.shariff)]

This change breaks hotplug for all network devices, because none of the wired, PPP, Bluetooth, etc. devices on my system have a DRIVER sysfs attribute. For example:

  looking at device '/class/net/eth0':
    KERNEL=="eth0"
    SUBSYSTEM=="net"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:06:01.0':
    KERNELS=="0000:06:01.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="8139too"

  looking at parent device '/devices/pci0000:00/0000:00:1e.0':
    KERNELS=="0000:00:1e.0"
    SUBSYSTEMS=="pci"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

It is only the parent device that has a driver.

The "DRIVER" line was later changed to "DRIVERS" in ifupdown_0.6.8ubuntu5, which is still problematic. It only runs the ifup/ifdown rules if /all/ devices in the chain have a driver, rather than running them if /any/ device has a driver. In other words, DRIVERS!="?*" works like (DRIVER!="?* [OR] parent.DRIVER!="?*" [OR] ...) instead of (NOT (DRIVER=="?*" [OR] parent.DRIVER=="?*" ...))

The simplest way I can think of to solve this is to remove the negation and add a DRIVERS="?*" clause to the individual add and remove rules. A patch implementing this solution is attached. It works correctly for the PPP case, since ppp devices have no DEVICE set nor any parent devices. It also works correctly for other hotpluggable devices (like bnep*), because they eventually have a USB device as a parent.

I suppose this problem went unnoticed thus far because of the rarity of hotpluggable network devices. I only noticed it now when my bluetooth PAN interface refused to come up automatically on connecting.

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

Thanks, the weird behaviour of S!= has been identified upstream and it isn't deliberate and will be fixed in a later udev release, for now I've uploaded a new ifupdown that reverses the test so that any device with a driver is auto-ifup'd, and others are not

[Alan (launchpad-atmurray)]

Roshan, one of the main bugs still exists in this patch. There is an extra "--" before "--allow auto" which is breaking the ifupdown filtering. Also, there should be no "=" after "--allow" as the syntax is "--allow CLASS".

I still think it would be better to create a "hotplug" class of interfaces to specify interfaces to be used by udev. This would give the user much clearer control over which interfaces are controlled by udev.

[Roshan Shariff (roshan.shariff)]

Alan,

AFAIK, the extra "--" indicates that start-stop-daemon should pass the
remaining arguments to ifup/ifdown, rather than trying to process them
itself. The start-stop-daemon(8) manpage says as much.

Also, ifupdown already says "--allow auto", not "--allow=auto", and my
patch doesn't change that. Indeed, network device hotplug works
perfectly on my system once the patch is applied, with an "auto bnep0"
line in /etc/network/interfaces

[David Pfeffer (davidp-bytenik)]

This is happening again on 10.04. I have no idea why, since 85-ifupdown.rules is now gone, but the same symptom occurs.

[Alan (launchpad-atmurray)]

Hi David,

Interestingly, the latest break hasn't been created by udev, it's been caused by upstart.
The culprit is
I think the solution (and this is consistent with how pppoeconf sets up the ppp interface) is not to mark ppp interfaces as 'auto'.
Instead, create an upstart script in /etc/init/ that calls /etc/ppp/ppp_on_boot when eth0 comes up.
For example:

# ppponboot - configure ppp network devices
#
# This task causes ppp connections to be started on boot.

description "configure ppp devices"

start on net-device-added INTERFACE=eth0

task

#the following is needed incase /var/run/network hasn't been created yet
#this can happen due to upstart's aggressive startup ordering
pre-start exec mkdir -p /var/run/network

post-start exec /etc/ppp/ppp_on_boot

[imagine (imagine-de)]

The documentation of the ppp package suggests that using /etc/ppp/pppoe_on_boot (or ppp_on_boot for the matter) is deprecated and users should instead set up the PPP connections in /etc/network/interfaces as "auto". The init-script which used this file in the past also doesn't exist anymore as far as I can see. So posting #8 looks more like a workaround than a solution for the problem.

Another workaround would be to exclude the PPP connections from being killed by Upstart by changing the post-stop action in /etc/init/network-interface.conf to something like:

post-stop script
    if [ "$INTERFACE" != ppp1 -a "$INTERFACE" != ppp2 ]; then
        exec ifdown --allow auto $INTERFACE
    fi
end script

However this is completely untested.
Be aware that up to and including Ubuntu 10.04, network-interface.conf is not set up as a configuration file in DPKG and therefore gets overwritten at each update without further notice.

[Maciej Rutkowski (maciej-rutkowski)]

I've stumbled upon this problem in Ubuntu Server 10.10 also, as my ISP is refreshing my dynamic IP every 24 hours.

imagine's workaround helps actually, although the problem should be fixed in a more generic way.

[FrankAu (terabite-4)]

The "post-stop" workaround is not effective in my situation.

I have documented the history so far in a forums thread (before discovering this bug report) at ...

   http://ubuntuforums.org/showthread.php?t=1918431

FWICT a nuanced difference to other reports may be the means by which pppd dies! In my case it seems to self destruct and I am not yet convinced any service (udev et al) is actually responding at all let alone responding incorrectly.

As mentioned in the bug (just marked as duplicate) #824596 I am looking to increase the logging levels to ascertain whom is doing what when.

First I have to bone up on Lucid upstart'isms being that I am somewhat of a Hardy curmudgeon.

[imagine (imagine-de)]

I use the workaround presented in posting #8 successfully in Ubuntu 10.04 and 10.10. So it's not without effect. I can't comment on why it doesn't work in your situation though. Maybe you forgot to change the connection names from ppp1 and ppp2 to whatever you use.

In any way, your root problem of a timing out ppp connection is unrelated to this bug. A faulty modem or an unstable line could be the cause for that. Also "LCP terminated by peer" suggests that the connection was closed by the remote side (after more than 8 days).

[Stéphane Graber (stgraber)]

Can someone post their /etc/network/interfaces?

I can see how that'd be a problem if your network device is "ppp0" in there, but last I checked it's not what's recommended.

Something along the lines of:
iface teksavvy-ipv4 inet ppp
    provider teksavvy-ipv4

Where teksavvy-ipv4 is the name of the profile in /etc/ppp/peers/ has been working perfectly here on 12.04.

[Teemu Torma (teemu-torma)]

I have been running something like the following setup on 10.04 for long time without unusal problems:

auto eth1
iface eth1 inet static
    post-up ifup ppplink
    pre-down ifdown ppplink
    ...

iface ppplink inet ppp
   provider myprovider

As far as I am concerned, this bug can be closed (I reported one of the duplicates).

[Alan (launchpad-atmurray)]

Stéphane, the following is an extract from my /etc/network/interfaces:

auto eth0
iface eth0 inet static
        address 10.0.0.251
        netmask 255.255.255.0
        ...

auto ppp0
iface ppp0 inet ppp
        pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
        provider internode

as you can see, I do have it named "ppp0".

Is the reason why the problem doesn't occur with other names that the $INTERFACES argument passed to /etc/init/network-interface.conf will always be "ppp0" and so if you have a name other than ppp0 in interfaces then it will ignore the unknown interface?

In my opinion, it is more consistent to configure ppp (especially pppoe) interfaces to always use the same pppX interface and also be configured as such in /etc/network/interfaces. That way if you "ifup ppp0" you know you're bringing up "ppp0". Running "ifup myprovider" or such and having the next available pppX interface come up isn't ideal for several reasons, the first being that it makes firewall configuration difficult if there is a chance that an interface will come up differently each time (imagine the case where you have to ppp interfaces and you want to firewall them differently).

Also, in your suggestion, you don't include "auto ppp0" which as far as I know is required to bring the interface up on boot and is how pppoe-conf will set up the interface if you request it to automatically come up on boot.
An alternative would be to have a post-up command as Teemu proposes, however this is not how pppoe-conf sets up the interface.

If the solution is to set up ppp interfaces as proposed by Teemu then I would suggest pppoe-conf needs to be changed to configure interfaces in the same way.

[Launchpad Janitor (janitor)]

[Expired for ifupdown (Ubuntu) because there has been no activity for 60 days.]