ifupdown plugin should not export any parsed connection configuration when running in managed=false mode (Was: Previously working DHCP on wired ethernet is assigned static IP from unrelated interface after upgrade to Intrepid)

Bug #291902 reported by Jamie Lokier
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
High
Alexander Sack
Intrepid
Fix Released
Medium
Alexander Sack

Bug Description

To verify:
1. with old package: add a simple configuration to /etc/network/interfaces that uses a non-existing interface name
   : iface eth-notexist inet dhcp
2. ensure that you have managed=false in /etc/NetworkManager/nm-system-settings.conf and restart everything
3. see that the eth-notexist config is availabe for wired interfaces in nm-applet
4. install new package and restart everything
5. eth-notexist shouldnt be visible in applet anymore

Proposed fix: for managed=false the ifupdown plugin should only parse the configuration, but dont export any connection config.

Binary package hint: network-manager

I'm using Intrepid Ibex, just upgraded from Hardy.

The version of network-manager is svn20081018t105859-0ubuntu1, but I don't know if that was the version which broke the configuration, or if network-manager has been upgraded in Intrepid since October 26th.

Since the upgrade, a previously working laptop with wired and wireless networks broke both. The wireless breakage is perhaps reported elsewhere; this is about the wired connection.

Previously, it would use DHCP on eth0 if there was a cable plugged in. Very sensible.

Now, the nm-applet dialog shows:

      Wired connections
      ifupdown (tap2)
      ifupdown (tap0)
      ifupdown (tap1)

      Wireless connections
      [access points if any]

When I plug a cable into eth0, it then assigns a _static_ configuration to eth0, which has no relevance to eth0. (This is the opposite of a bug others have reported where static configurations change to DHCP after upgrade :-) )

Specifically, after plugging in a cable, nm-applet shows it has selected "ifupdown (tap1)", and is applying static IP 10.1.1.1 to _eth0_, which is the static IP that is given for tap1 in /etc/network/interfaces.

My full /etc/network/interfaces, with comments removed, is as follows:

auto lo
iface lo inet loopback

iface ppp0 inet ppp
        provider BluetoothDialup
iface ppp1 inet ppp
        provider free-dialup
iface ppp2 inet ppp
        provider cameldial
iface ppp3 inet ppp
        provider freeukisp
iface ppp4 inet ppp
        provider 123-reg
auto ppp0
auto tap0
iface tap0 inet static
      address 10.1.100.1
      netmask 255.255.255.0
      tunctl_user jamie
auto tap1
iface tap1 inet static
      address 10.1.1.1
      netmask 255.255.255.0
      tunctl_user jamie
auto tap2
iface tap2 inet static
      address 10.1.2.1
      netmask 255.255.255.0
      tunctl_user jamie

Sometime in the past, it also has "auto eth0" and maybe "iface eth0 inet dhcp", but I removed those to let NetworkManager handle eth0 in Hardy.

Intrepid selected "ifupdown (tap1)" and proceeds to set eth0 to its settings, which have never been appropriate for eth0:

jamie@amilo:~$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:16:36:4f:e6:80
          inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0
          inet6 addr: fe80::216:36ff:fe4f:e680/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:5265 (5.2 KB)

So my questions / bug report are:

    - Why did it create "ifupdown (tap0)" (+tap1, +tap2) connections? (I can see them in Edit Connections in nm-applet, btw).

    - Having imported data for those connections on upgrade to Intrepid, why does it then _apply_ the settings for tap1 to eth0???!!!! That is obviously wrong.

    - Why does it not have a DHCP connection under the Wired Networks created, since that's what eth0 was doing before the upgrade.

I've worked around this by running "sudo dhclient eth0", and later by creating another connection in Edit Settings called simply "DHCP", and explicitly selecting that. I've no idea what the normal process would have called the connection, and it's kind of ugly to have: "Wired Settings" "DHCP" in nm-applet's main window, but that's purely cosmetic.

I'd provide a screenshot, but Alt-PrintScreen doesn't work when nm-applet's main selection window is popped up.

Thanks.

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :
Revision history for this message
Alexander Sack (asac) wrote :

For NM everything in /etc/network/interfaces are just connection configuration - which are not bound to a particular device ... unless the names match devices NMis supposed to manage. So NM will consider them for devices that don't have any other explicit configuration.

My suggestion would be to configure eth0 and eth1 in interfaces too and if you still want to use NM, try to use managed=true in /etc/NetworkManager/nm-system-settings.conf

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :
Download full text (5.5 KiB)

<i>For NM everything in /etc/network/interfaces are just connection configuration - which are not bound to a particular device ... unless the names match devices NMis supposed to manage. So NM will consider them for devices that don't have any other explicit configuration.</i>

This seems a very odd behaviour, as it's contrary to what /etc/network/interfaces means.

Does NM do anything else surprising with /etc/network/interfaces, like parse the comments, look for special keywords, or invent random numbers? I'm just wondering, because taking a static IP configuration for one interface and automatically applying it to a different interface seems like would never be the right thing to do. Is there a rationale for this behaviour - i.e. a situation where it makes sense?

(By the way, why does it use the unrelated interface configurations as possible configs for eth0, but not for wlan0?)

If it makes no sense, I suggest removing it! But if there are scenarios where it makes sense - it really could do with being a controllable option.

I do still want to use NM, as it works quite well for wireless interfaces when roaming. (When it handles Bluetooth 3g broadband, that will be really nice.)

In Hardy it worked for wired ethernet too - if that was plugged in, it used it, and if not, it looked for a wireless signal. (On Hardy, I still had to kill and restart NM whenever I used 3g broadband or PPP, but NM's wired/wireless behaviour is very useful).

If I follow your suggestion of putting eth0 in NM, that would prevent NM from managing eth0 wouldn't it? But managing eth0 - like wireless - is useful behaviour that worked in Hardy. The useful behaviour was detecting when a cable is plugged in, and running DHCP.

In my situation, does NM also touch the tap0 / tap1 / tap2 / tun0 / bnep0 / pan0 interfaces which are found on my laptop, or does it just manage eth0 and wlan0?

From reading /usr/share/doc/network-manager/README.Debian, I guess it won't manage tap0 / tap1 / tap2 because those are mentioned in /etc/network/interfaces - but it _will_ try to manage tun0 (which is created by OpenVPN) and bnep0 (which is created by Bluez pand), and pan0 (which is created by something I don't know about, but connected with Bluetooth somehow). Is that correct?

Your suggestion to try managed=true is... puzzling. README.Debian explains that this causes NM to manage all the interfaces - but what I (think I) need is for NM to manage eth0 and wlan0, but not any other interfaces (whether mentioned in /etc/network/interfaces or not), and not to read the configurations of unrelated interfaces from /etc/network/interfaces as potential eth0 configurations.

Neither managed=false nor managed=true will achieve that according to my reading of the docs.

But I'll try managed=true, since I'm curious what "managed all the interfaces in /etc/network/interfaces and honours all the DHCP / static settings" really means :-)

Ok, tried it. Restarted /etc/init.d/NetworkManager restart. The GUI shows exactly the same as before: "ifupdown (tap0)" (+ tap1 and tap2) under Wired Networks, and when a wire is plugged in I expect it to use a faulty static config from tap1 as before. There...

Read more...

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

"putting eth0 in NM" should read "putting eth0 in /etc/network/interfaces"

Revision history for this message
Alexander Sack (asac) wrote :

well. /etc/network/interfaces is the real hoax ... not NM ... there is nothing that guarantees that you eth0 is actually eth0 ... on next reboot you might end up having eth1 as eth0 ... or even wlan0 as eth0.

NM is right, ifupdown is rotten old. You configure connections and if you want to lock them to a particular device you configure the mac address.

if you use managed=true (experimental) mode NM will use the info from /e/n/interfaces to lock the config from there automatically to the right device. anyway, you can also just set the mac in your connection setting and all is fine... and much more reilable than ifupdown.

Changed in network-manager:
status: New → Invalid
Revision history for this message
Alexander Sack (asac) wrote :

sorry ... confirmed i mean. for managed=false the ifupdown plugin should only parse the configuration, but dont export any connection config.

Changed in network-manager:
importance: Undecided → High
status: Invalid → Triaged
Revision history for this message
Alexander Sack (asac) wrote :

SRU worthy as the fix is quite easy and should remove lots of confusion in managed=false mode

Changed in network-manager:
importance: Undecided → Medium
milestone: none → intrepid-updates
status: New → Triaged
description: updated
Alexander Sack (asac)
description: updated
Martin Pitt (pitti)
Changed in network-manager:
assignee: nobody → asac
assignee: nobody → asac
Revision history for this message
Alexander Sack (asac) wrote :

rev2965

Changed in network-manager:
status: Triaged → Fix Committed
Alexander Sack (asac)
description: updated
Revision history for this message
Alexander Sack (asac) wrote :

upload SRU: network-manager_0.7~~svn20081018t105859-0ubuntu1.8.10.1_source.changes to ubuntu/intrepid-proposed

Changed in network-manager:
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.7~~svn20081018t105859-0ubuntu2

---------------
network-manager (0.7~~svn20081018t105859-0ubuntu2) jaunty; urgency=low

  * fix LP: #292054 - Some drivers take too long to associate (Was:
    network-manager 0.7 always asks for WPA passphrase); we workaround
    this driver/wpasupplicant bug by giving association more time
    (e.g. 60sec instead of 25sec)
    - add debian/patches/lp292054_tune_supplicant_timeout_60s.patch
    - update debian/patches/series
  * fix LP: #256905 - dbus policy file (nm-avahi-autoipd.conf) not properly
    deployed in package; install nm-avahi-autoipd.conf
    - update debian/network-manager.install
  * fix LP: #282207 - [Sierra] NM 0.7 does not set APN for AT&T 3G connection;
    apply fix from Jerone Young
    - add debian/patches/lp282207_set_apn_at_syntax.patch
    - update debian/patches/series
  * fix LP: #268667 - not all required ppp options get set on command line
    which makes ppp use bad values from /etc/ppp/options; we backport upstream
    fix
    - add debian/patches/lp268667_more_ppp_default_options.patch
    - update debian/patches/series
  * fix LP: #291564 - ifupdown network manager does not blacklist/unmanage
    mapped devices in managed=false mode; thanks to Stephan Trebels for the
    patch
    - add debian/patches/lp291564_ifupdown_unmanage_mapping_and_iface.patch
    - update debian/patches/series
  * fix LP: #291902 - ifupdown plugin should not export any parsed connection
    configuration when running in managed=false mode; we fix this by exporting
    empty connection list in unmanaged mode
    - add debian/patches/lp291902_IFUPDOWN_dont_export_connection_in_unmanaged_mode.patch
    - update debian/patches/series
  * belt-and-braces fix LP: #290468 VPN fails, "/usr/bin/nm-ppp-starter
    missing"; we remove obsolete conffiles in -pptp .preinst; in case user
    modified them they will be renamed to .dpkg-bak; this patch takes care that
    NM doesn't consider files in /etc/NetworkManager/VPN that don't have a
    .name filename suffix.
    - add debian/patches/lp290468_only_consider_name_suffix_VPN_service_files.patch
    - update debian/patches/series
  * fix LP: #303142 - 3G [Option] some modems take a while time to register on
    network (CREG); we use g_timeout_add instead of _idle_add to give the
    modem some rest during registration phase.
    - add debian/patches/lp303142_more_time_for_automatic_registration.patch
    - update debian/patches/series

 -- Alexander Sack <email address hidden> Fri, 28 Nov 2008 13:47:07 +0100

Changed in network-manager:
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted network-manager into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in network-manager:
milestone: intrepid-updates → none
status: In Progress → Fix Committed
Revision history for this message
Alexander Sack (asac) wrote :

someone, please test this. For me it works.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.7~~svn20081018t105859-0ubuntu1.8.10.1

---------------
network-manager (0.7~~svn20081018t105859-0ubuntu1.8.10.1) intrepid-proposed; urgency=low

  * fix LP: #292054 - Some drivers take too long to associate (Was:
    network-manager 0.7 always asks for WPA passphrase); we workaround
    this driver/wpasupplicant bug by giving association more time
    (e.g. 60sec instead of 25sec)
    - add debian/patches/lp292054_tune_supplicant_timeout_60s.patch
    - update debian/patches/series
  * fix LP: #256905 - dbus policy file (nm-avahi-autoipd.conf) not properly
    deployed in package; install nm-avahi-autoipd.conf
    - update debian/network-manager.install
  * fix LP: #282207 - [Sierra] NM 0.7 does not set APN for AT&T 3G connection;
    apply fix from Jerone Young
    - add debian/patches/lp282207_set_apn_at_syntax.patch
    - update debian/patches/series
  * fix LP: #268667 - not all required ppp options get set on command line
    which makes ppp use bad values from /etc/ppp/options; we backport upstream
    fix
    - add debian/patches/lp268667_more_ppp_default_options.patch
    - update debian/patches/series
  * fix LP: #291564 - ifupdown network manager does not blacklist/unmanage
    mapped devices in managed=false mode; thanks to Stephan Trebels for the
    patch
    - add debian/patches/lp291564_ifupdown_unmanage_mapping_and_iface.patch
    - update debian/patches/series
  * fix LP: #291902 - ifupdown plugin should not export any parsed connection
    configuration when running in managed=false mode; we fix this by exporting
    empty connection list in unmanaged mode
    - add debian/patches/lp291902_IFUPDOWN_dont_export_connection_in_unmanaged_mode.patch
    - update debian/patches/series
  * belt-and-braces fix LP: #290468 VPN fails, "/usr/bin/nm-ppp-starter
    missing"; we remove obsolete conffiles in -pptp .preinst; in case user
    modified them they will be renamed to .dpkg-bak; this patch takes care that
    NM doesn't consider files in /etc/NetworkManager/VPN that don't have a
    .name filename suffix.
    - add debian/patches/lp290468_only_consider_name_suffix_VPN_service_files.patch
    - update debian/patches/series
  * fix LP: #303142 - 3G [Option] some modems take a while time to register on
    network (CREG); we use g_timeout_add instead of _idle_add to give the
    modem some rest during registration phase.
    - add debian/patches/lp303142_more_time_for_automatic_registration.patch
    - update debian/patches/series

 -- Alexander Sack <email address hidden> Fri, 28 Nov 2008 13:48:34 +0100

Changed in network-manager:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.