network-manager should stop managing any interface configured in /etc/network/interfaces

[Alexander Sack]

Binary package hint: network-manager

network manager should stop to manage _any_ interface that is configured in /etc/network/interfaces.

Rational: network-manager and ifupdown concepts do not match; not blacklisting interfaces configured in /etc/network/interfaces causes bugs, unexpected behaviour and confusion, because it breaks the auto dhcp feature of ifupdown.

Actions needed:

 1. network manager should blacklist _all_ interfaces configured in /e/n/i.
 2. in postinst, network manager should #-comment interfaces in /e/n/i that were previously not blacklisted; of course, only if the upgrade comes from a NM version that didn't blacklist those interfaces (e.g. <= 0.6.5-0ubuntu11).
 3. desktop installer should not add auto dhcp interfaces.

[Alexander Sack (asac)]

meeting log:

17:50 < asac> pitti: please rephrase :) ?
17:51 < pitti> ok, I plug my laptop into my ethernet and have auto eth0/dhcp
17:51 < asac> yeah
17:51 < pitti> (in /e/n/i)
17:51 < pitti> then I unplug it, and want to use my wifi
17:51 < pitti> but since n-m doesn't manage eth0 any more, the default route won't be torn down for eth
17:51 < pitti> (and neither the dhclient)
17:52 < pitti> i. e. everyone who every uses network-admin will be stuck there
17:52 < asac> what happens if you have two default routes?
17:52 < pitti> oh, you can switch it back to 'roaming'
17:52 < asac> for me it worked
17:52 < pitti> asac: you lose
17:52 < pitti> asac: it's a race condition, from my experience
17:52 < pitti> sometimes it works, sometimes you lose all packets
17:53 < pitti> it's bit of a corner case, yes, but so far these cases were handled pretty well because n-m actually understood
               /e/n/i
17:53 < pitti> I know, choosing between two evils :/
17:53 < asac> pitti: understood is a bit exaggerated
17:53 < asac> it broke ifupdown :)
17:54 < pitti> IOW, once someone configures "dhcp" in network-admin for eth0, n-m will just go to 'static configuration' and not
               do anything any more
17:54 < pitti> might be a bit confusing
17:54 < asac> he?
17:54 < ogra> who?
17:54 < asac> it will not go to static ... it will just stop to manage it
17:55 < pitti> asac: right, but it won't switch interfaces either because you have a manual configuration
17:55 < asac> can't dhclient listen to hal events?
17:55 < pitti> unless, of course, n-m continues to actually parse and interpret /e/n/i, but I thought you wanted to get rid of
               that
17:56 < pitti> asac: in what way?
17:56 < asac> remove/add route?
17:56 * pitti does not understand; why should dhclient do that?
17:56 < pitti> after all, dhclient *is* the bit that actually configures routes...
17:56 < asac> i don't mean dhclient .. i mean ifupdown mechanism
17:56 < ogra> asac, you could use route directly :)
17:57 < pitti> asac: there's no ifupdownd or something that could do that; what should it do?
17:57 < ogra> pitti, he wants to remove the defaultroute for that interface if i understood right
17:57 < ogra> but keep the interface as is
17:58 < pitti> asac: if we want n-m to override ifupdown routes, then we could make ifupdown use defualtroutes with metric 1
17:58 < asac> pitti: how would that look like?
17:58 < pitti> and keep n-m use metric 0 routes
17:58 < pitti> so that n-m's routes win
17:58 < asac> yes that sounds reasonable then
17:58 * asac has not idea about metrics
17:58 < pitti> asac: just "metric 1" option
17:59 < pitti> asac: just think about it as 'priority'
17:59 < asac> yeah ... were would such a feature be added?
17:59 < pitti> the lower one wins

[Alexander Sack (asac)]

as discussed in previous irc log we want to add a default metric to all ifupdown managed routes unless an explicit metric is configured in /etc/network/interfaces.

Adding ifupdown to bug and targetting for 7.10 beta.

[Alexander Sack (asac)]

Patch to set route metric to 100 unless there is metric definition in the /etc/network/interfaces iface block. ATM, we do this for static + dhcp inet iface definitions only.

[Alexander Sack (asac)]

network manager invokes this script during postinst configure like:

                if dpkg --compare-versions "$2" "<<" 0.6.5-0ubuntu12; then
                    sh /usr/lib/network-manager/ifblacklist_migrate.sh
                fi

[Colin Watson (cjwatson)]

netcfg (1.39ubuntu3) gutsy; urgency=low

  * Call /usr/lib/network-manager/ifblacklist_migrate.sh from finish-install
    if present, so that 'auto dhcp' interfaces are disabled if
    network-manager is in use (LP: #139403).

 -- Colin Watson <email address hidden> Wed, 19 Sep 2007 12:38:08 +0100

[Colin Watson (cjwatson)]

ubiquity just copies the /etc/network/interfaces generated by casper, so this goes hand in hand with using n-m properly on the live CD.

[Colin Watson (cjwatson)]

casper (1.103) gutsy; urgency=low

  * Disable anacron harder so that it doesn't get started by battery events.
  * Don't write out DHCP network interface stanzas if network-manager is
    installed (LP: #139403).

 -- Colin Watson <email address hidden> Wed, 19 Sep 2007 12:52:21 +0100

[Martin Pitt (pitti)]

The ifupdown change looks good to me. I gave it some extensive testing on my desktop (eth only) and laptop (eth+wifi) with various metric options and configurations.

[Alexander Sack (asac)]

network-manager (0.6.5-0ubuntu12) gutsy; urgency=low

  * debian/patches/05-debian_backend.patch: don't manage auto/allow-* dhcp
    interfaces anymore (LP: #139403).
    - debian/ifblacklist_migrate.sh: new helper script that blacklists
      auto/allow-* dhcp interfaces without any options.
    - debian/network-manager.install: install helper script to $pkglibdir
    - debian/network-manager.postinst: run ifblacklist_migrate.sh during
      configure when upgrading from versions "lt-nl" 0.6.5-0ubuntu12.
  * debian/changelog: add merge-dropped changelog entries for 0.6.3-2ubuntuX
    revision series (LP: #124018)
  * debian/patches/25_lp90267-dont-tear-down-upped-interfaces.patch,series:
    drop this patch, so nm is allowed to tear down upped interfaces during
    startup again.

 -- Alexander Sack <email address hidden> Wed, 19 Sep 2007 18:38:17 +0200

[Alexander Sack (asac)]

ifupdown (0.6.8ubuntu8) gutsy; urgency=low

  * ifupdown.nw: use 100 as default route metric unless an explicit metric
    parameter is set in /etc/network/interface; this applies for static and
    dhcp interfaces and passes the -e IF_METRIC=%metric% option to dhclient{3}
    in order to accomplish this. For details see the launchpad bug
    (LP: #139403).

 -- Alexander Sack <email address hidden> Thu, 20 Sep 2007 00:38:33 +0200

[Martin-Éric Racine (q-funk)]

That somehow completely broke wifi support here.

I have tried purposely commenting out ath0 and wifi0 and restarting both networking and dbus, but that didn't help; the nm-applet keeps on dying.

I ended up having to manually associate the essid and launch dhcp from interfaces by defining ath0 there.

[Alexander Sack (asac)]

Martin, your crash is most likely dealt with in bug 141233 and its duplicate.

[Martin-Éric Racine (q-funk)]

Alexander, that might well be the case. I'll wait until the fix is built and pushed and then comment on the appropriate bug if necessary.

[martinlanghoff (martin-langhoff)]

Hi Alexander - I am seeing problems with network-manager / network-manager-gnome that seem related to this. At least the bugs that seem to describe it are marked as dups of this one ;-)

The symptom I see is that network-manager is *not* managing my wired network, when it should. At the office I have both a wired LAN, and a wifi signal. Network manager is choosing the wifi signal and not allowing me to revert to the wired LAN. This symptom is similar to what is reported under #126494 . This is with current gutsy witn network-manager 0.6.5-0ubuntu14 and network-manager-gnome 0.6.5-0ubuntu9 .

I _can_ get the networking infrastructure to use the LAN, saying `sudo ifdown eth1` but then NM thinks we have no network, and doesn't let me use the VPNs I have configured. So this is quite an awkward regression.

Does the statement that "network manager should stop to manage _any_ interface that is configured in /etc/network/interfaces" mean that for things to work well I have to remove eth0 from /etc/network/interfaces? How about lo?

[shanen (Shannon Jacobs) (shanen)]

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/133374 was where I came from, and that description seems to match my problem very exactly. However, it is listed as a duplicate of this bug, and when I read this one I am unable to understand the relationship.

To recap: After booting, the computer is not connected to the network. If I disable the network and enable it again, then it will connect and work normally.

I have not seen any similar problems on about half-a-dozen machines that I've installed Ubuntu on, but this installation is my first on a Sharp notebook. I've looked at the nine basic logs, but failed to find the parts corresponding to the stuff described in bug 133374.

[Alexander Sack (asac)]

On Sun, Sep 30, 2007 at 07:08:27PM -0000, martinlanghoff wrote:
> Does the statement that "network manager should stop to manage _any_
> interface that is configured in /etc/network/interfaces" mean that for
> things to work well I have to remove eth0 from /etc/network/interfaces?
> How about lo?
>

either remove your wired interface from /etc/network/interfaces or
disable/mark-for-roaming that device in System -> Administration ->
Network.

Thanks,

 - Alexander

[shanen (Shannon Jacobs) (shanen)]

Though the last comment from Alexander wasn't addressed to me, I hoped to apply it, but roaming was not selected, and my wired interface is not listed in /etc/network/interfaces.

I have done some more experiments, but still have no real understanding of the problem. I still can't even understand why this is marked as the parent bug of the duplicate that actually seems to match the problem I'm seeing... However, it doesn't seem to be a widespread problem. (Either that, or the people who have it mostly can't figure out how to get on the network so that they can report it.)

[Andreas Endler (mail-desadre)]

Hi @all,

this is my first post on the launchpad - so please excuse any formal mistakes.

What you've described, I've also figured out. It's really frustating, that after bootup I do never have an internet connection automatically.
My "/etc/network/interfaces" is empty except the "auto lo" entry and I've enabled the roaming mode for the wired connection. But on bootup my eth0 (I have only this device for networking) will be deactivated every time. I need then to "deactivate network" and "activate network" on the n-m icon at the gnome-panel to get online. Does anyone have a suggestion, how this could be solved?

entries in /var/log/syslog

during the boot up:

...
NetworkManager: <info> Updating allowed wireless network lists.
NetworkManager: <WARN> nm_dbus_get_networks_cb(): error received: org.freedesktop.NetworkManagerInfo.NoNetworks - There are no wireless networks stored..
kernel: [ 98.348000] NET: Registered protocol family 10
kernel: [ 98.348000] lo: Disabled Privacy Extensions
kernel: [ 98.348000] ADDRCONF(NETDEV_UP): eth0: link is not ready

and now the deactive/activate action:

NetworkManager: <info> Disconnected.
NetworkManager: <info> Enabling networking.
NetworkManager: <info> Deactivating device eth0.
kernel: [ 250.216000] ADDRCONF(NETDEV_UP): eth0: link is not ready
NetworkManager: <info> eth0: Device is fully-supported using driver 'uli526x'.
NetworkManager: <info> nm_device_init(): waiting for device's worker thread to start
NetworkManager: <info> nm_device_init(): device's worker thread started, continuing.
NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'.
NetworkManager: <info> Deactivating device eth0.
kernel: [ 253.216000] uli526x: eth0 NIC Link is Up 100 Mbps Full duplex
kernel: [ 253.216000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
NetworkManager: <info> Will activate wired connection 'eth0' because it now has a link.
NetworkManager: <info> SWITCH: no current connection, found better connection 'eth0'.
dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason
NetworkManager: <info> Will activate connection 'eth0'.
NetworkManager: <info> Device eth0 activation scheduled...
NetworkManager: <info> Activation (eth0) started...
NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager: <info> Activation (eth0) Beginning DHCP transaction.
NetworkManager: <info> Activation (eth0...

[shanen (Shannon Jacobs) (shanen)]

I'm still not sure it's the same underlying problem that I'm trying to report, and I wish someone would post a clear diagnostic test here. What I can say is that the problem has survived the Gutsy upgrade. The workaround of disabling and then enabling networking still works to fix it. I've only upgraded two machines so far, but there was no sign of network-related problems with the other one. It's only my Sharp notebook PC-WA70L that has the problem.

[Jojo (kuzniarpawel)]

It seems that I'm also affected by this particular problem on my old Hp Omnibook XE2. I've got roaming mode enabled and network manager applet sees wired connection, but never connects to it right away after boot. I must manually choose wired connection, to receive ip address. My network card is 3c589D pcmcia.

I include my lspci below.

[Jojo (kuzniarpawel)]

I don't know, whether it is exactly the same bug, but for me fix released didn't solve the problem.

[Bartek Celary (karaphka)]

I am on 8.10 and have following cards: eth1 + ath1 (both wireless). Now I would like to be able to use eth1 as usually without the other one connecting to the same network (which is cause strange delays while fetching web pages). So I decided to add ath1 to interfaces file:

iface ath1 inet manual

I have also tried adding 'auto ath1' but this does not change anything.

But it seems NM is happy to manage ath1 anyways... It looks to me this is the same bug... (correct me if I'm wrong, and if so - how should I blacklist an interface from the NM?)

BTW - NetworkManager is very poorly documented, is it really the case or have I missed something obvious (the code obviously, but I am not talking about this kind of documentation ;) ).