IPv4 connectivity broken after installing from ubuntu-12.04-alternate-amd64.iso

Bug #995165 reported by David on 2012-05-05
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
High
Mathieu Trudel-Lapierre
Precise
High
Mathieu Trudel-Lapierre

Bug Description

[Impact]
IPv6 is becoming increasingly popular and installations on IPv6-ready networks are becoming more frequent; this issue affects installations of the Desktop image from the alternate image (or using d-i in any other way) when IPv6 autoconfiguration or DHCPv6 is used. These installations will fail to recognize that the interface should be managed by NetworkManager after the installation because only the "iface X inet dhcp" line would be commented out, leaving another valid "iface X" line for "inet6" causing NetworkManager to ignore the device. The solution was to comment out all lines in /etc/network/interfaces pertaining to interface X: "auto X", "iface X inet", and "iface X inet6".

[Test Case]
1a) With IPv6 autoconfiguration (for example, using radvd) or DHCPv6 available on the network:
1b) With no IPv6 available on the network:
2) Install Ubuntu from the alternate CD; or using d-i via a netboot image.
3) After the installation:
 a) Verify that NetworkManager properly handles all interfaces.
 b) Verify that the network interfaces configuration is commented out in /etc/network/interfaces.

[Regression Potential]
Untypical configurations may find devices that should be ignored by NetworkManager to be handled by it. Standard installations could fail to comment the necessary information from /etc/network/interfaces to allow for NetworkManager to do is job; or the file could be mangled to remove the "lo" interface, which would make unrelated services fail.

---

To reproduce:
- Download ubuntu-12.04-alternate-amd64.iso
- Burn it to a USB flash drive from a completely up-to-date Ubuntu 10.04 LTS with UNetbootin
- Install on a machine with both IPv4 and IPv6 connectivity
- Log in to the newly installed system

Current behaviour:
- There is no IPv4 connectivity
- NetworkManager doesn't show the wired interface in its dropdown

Expected behaviour:
- There is IPv4 connectivity
- NetworkManager does show the wired interface in its dropdown

Thoughts:
I suspect this is because during the install my /etc/network/interfaces was created like so:
---BEGINS---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto
---ENDS---

Then network-manager-0.9.4.0/debian/ifblacklist_migrate.sh mutates the file to comment out a single line like so:
#NetworkManager#iface eth0 inet dhcp

i.e. the line
iface eth0 inet6 auto
remains intact

This means that the /etc/network/interfaces file gives me IPv6 connectivity but not IPv4 connectivity. Furthermore, because there is an uncommented iface eth0 inet6 line, NetworkManager doesn't show me the interface in its dropdown.

To fix:
- The regular expression needs to be changed so that the iface eth0 inet6 auto line is also commented out

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Dahu (spadayoo-launchpad) wrote :

I had the same problem and simply commenting the line
iface eth0 inet6 auto
resolved the problem.

Georg Müller (georgmueller) wrote :

I think this is not a bug of network-manager but of the installer who creates /etc/network/interfaces ...

This line should not be created in the first place.

Carl Young (carlyoung-p) wrote :

I have also seen this in 12.04 LTS AMD 64. In my failing environment, interface->dhcp is 1; interface->slaac is 1, and interface->dhcp6 is 0. The install syslog shows:

Network config complete
Writing informative header
Success!
Writing loopback interface
Success!
Writing DHCP stanza for eth0
Writing SLAAC stanza for eth0
Success!

/etc/network/interfaces shows as follows (sans some comments at top)

===== START =====
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#NetworkManager#iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto
===== END =====

If I comment out the #NetworkManager# comment, then my network is fine - ifconfig shows IPv4 and IPv6 addresses, but the Network manager reports unmanaged.

Carl Young (carlyoung-p) wrote :

This bug seems releated to 948217 and several others. In my case, during a netboot install I have an IPv4 DHCP assigned address and IPv6 global addresses assigned by SLAAC. This then ends up with two iface entries in /e/n/interfaces:

iface eth0 inet dhcp
iface eth0 inet6 auto

The ifblacklist_migrate.sh script locates and disables the first entry, but not the second (and I don't think it has a way of knowing this is SLAAC so can't disable it?)

Carl Young (carlyoung-p) wrote :

Precise Alternate CD comes with netcfg 1.68 (netcfg_1.68ubuntu14_amd64.udeb) and this version of netcfg writes out two iface entries for eth0 when it has dhcp/dhcp6 assigned or SLAAC assigned global IPv6 addresses (write_interface.c).

The ifblacklist_migrate.sh only disables the first entry because of the dhcp tag, and doesn't disable the second, so we end up with an unmanaged NIC according to NetworkManager and no IPv4 address.

Nice catch, that's indeed a wrong assumption on the part of the ifblacklist_migrate.sh script -- I'll look at fixing this ASAP; but anyone wanting to take a stab and that funky sed line in ifblacklist_migrate.sh is welcome to do so ;)

Changed in network-manager (Ubuntu):
importance: Undecided → High
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Carl Young (carlyoung-p) wrote :

I checked out the sed line and I think I've just about got over the trauma now...

From my 'newb' PoV, I would also be looking at netcfg and why there is no distinction between link-local auto-assigned IPv6 addresses and SLAAC auto-assigned global IPv6 addresses and how NetworkManager handles IPv6.

Where I have an installation that is NetworkManager managed - it has a commented out "iface eth0 inet dhcp" entry but no IPv6 entry at all, ifconfig still shows that I have an IPv6 link-local (fe80::/64) address. I guess this is because the IPv6 support is built into the kernel itself?

Can something (a keyword?) be introduced into the inet ipv6 stanza to distinguish the address classes to assist ifblacklist_migrate.sh?

Not needed, there's a new ifblacklist_migrate.sh available in the quantal package already; I'll just need to fix it up for a Precise SRU.

Changed in network-manager (Ubuntu Precise):
status: New → Confirmed
importance: Undecided → High
Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
Changed in network-manager (Ubuntu Precise):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
description: updated

Hello David, or anyone else affected,

Accepted network-manager into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/network-manager/0.9.4.0-0ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in network-manager (Ubuntu Precise):
status: Confirmed → Fix Committed
tags: added: verification-needed

Carl, David,

Are you able to test this? Enabling proposed for the install might be a little tricky, but you can look at https://wiki.ubuntu.com/Testing/EnableProposed (the section "Installation testing with -proposed") to know how to run the tests and get the updated network-manager package.

Carl Young (carlyoung-p) wrote :

Hi Mathieu, I have been moved into a different development group, so I don't have the facility to try this any more. I have asked my guys in Hyderabad if they can try this as they now own the lab environment.

Regards, Carl

BubbaJ (azstuenthome) wrote :

Mathieu, How can this be tested so that the other chages tied to the same fix can be released? I've been waiting on the fix to bug #1035590, which 0.9.4.0-0ubuntu4.2 has been confirmed to resolve. But the package is being held up it seems because no testing has been completed for this bug. I don't have IPv6 on my network, and probably many others do not as well. Forgive me, but is there anyway to release the change without the bug fix for #995165 if no one is willing to test it?

Marius B. Kotsbak (mariusko) wrote :

I have a Precise installation in a IPv6 network, but it works properly. How can I test the fix? By adding the line "iface eth0 inet6 auto"?

Marius B. Kotsbak (mariusko) wrote :

Nope, I'm unable to reproduce the problem by adding "iface eth0 inet6 auto" and "iface eth0 inet dhcp" and running restart networking. I have not enabled proposed updates. Are there any other steps in the reproduction? I'm not sure that this machine has used the alternate installation, and it has been upgraded at least once.

Carl Young (carlyoung-p) wrote :

Hi. Sorry I haven't been able to get anyone to retry at my site, but they are in final sprints of product release. In my scenario, where I saw the failures, there would have been existing Windows-based machines with auto-assigned (link-local) IPv6 addresses but no 'real' IPv6 infrastructure.

If someone can given the manual steps to try verifiying the fix, they have given me access to their test environment. As I'm not really an Ubuntu expert (sorry), I would appreciate the steps required to test the fix including how I would patch, etc.

BubbaJ (azstuenthome) wrote :

Is there anyone who can test this so that the fix can be released for this and the other three bugs? I would test this if I could. Any help from anyone would be greatly appreciated.

Carl Young (carlyoung-p) wrote :

I previously said: "If someone can given the manual steps to try verifiying the fix, they have given me access to their test environment. As I'm not really an Ubuntu expert (sorry), I would appreciate the steps required to test the fix including how I would patch, etc."

If someone can tell me where to get the binaries and how to apply them to asn appropriate ISO or mirror, I can get access to the emvironment to test this behaviour.

You don't need to apply anything; you can test this by simply running an install (provided you have IPv6 connectivity when you do so; reproducing the actual bug), and enabling proposed for the install: see https://wiki.ubuntu.com/Testing/EnableProposed (the section "Installation testing with -proposed" at the end).

For the curious; that's just by adding the "apt-setup/proposed=true" boot parameter as you boot from an alternate CD -- you don't need to download any special installer image (you don't need the first link in the wiki page mentioned above).

Mark Russell (marrusl) wrote :

I've verified the fix in proposed using the precise mini.iso. With IPv6 enabled on the router, I was able to duplicate the issue. Reinstalling with proposed enabled in the kernel command-line worked as expected (with IPv4 connectivity).

tags: added: verification-done
removed: verification-needed

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu4.2

---------------
network-manager (0.9.4.0-0ubuntu4.2) precise-proposed; urgency=low

  * debian/patches/git_use_wpa_wext_methods_50435e1.patch: use the same kind
    of logic as wpasupplicant instead of just looking at whether a driver
    reports signal over nl80211 to decide whether to use that or fallback
    to wext. (LP: #1035590)
  * debian/patches/ipw2x00-no-nl80211.patch: replaced by the patch above.
  * debian/patches/git_ignore_ipconfig_dups_cca4052.patch: silently ignore
    duplicates in NMIP[46]Config objects; which tends to happen fairly
    regularly with RDNSS. (LP: #996032)
  * debian/patches/nm-ipv6-route-cache.patch: don't re-add routes we receive
    from kernel notifications to the routing table if they have the
    RTM_F_CLONED flag; since that means they're host routes used temporarily
    by the kernel to reach a specific destination; keeping them would cause at
    least issues with VPNs, and possibly confusion with routing daemons.
    Thanks to Ben Jenks for the patch. (LP: #1038541)
  * debian/ifblacklist_migrate.sh: make sure that "iface X inet6" entries added
    by d-i also get commented out if set up for dhcp or auto -- this follows
    what is already done for IPv4, where such devices should be handled by
    NetworkManager. This fixes issues where people installing using d-i and
    where IPv6 autoconfiguration is available would get their interfaces
    ignored by NetworkManager when installing desktop. (LP: #995165)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 10 Oct 2012 17:31:55 -0400

Changed in network-manager (Ubuntu Precise):
status: Fix Committed → Fix Released
BubbaJ (azstuenthome) wrote :

Thanks all for completing the testing on this bug so that this and other fixes could be released. I appreciate it as this was the last bug that required testing before the most recent proposed change could be released.

Maurice Johnson (103730258b) wrote :

Read your post but I can't find "Download ubuntu-12.04-alternate-amd64.iso, sha256sum: f8d54df0afbab6a6248f6e2bcab3e68f01c04d52b0bb1f889d880ad3bc881ccb" there are other .iso's websites i.e
http://nl.releases.ubuntu.com/precise/
The issue seems to be md5sum failure or sha256sum failure to match. Where can I find your version?
Thanks,
M J

description: updated
Download full text (7.6 KiB)

Thanks for taking the time to respond to my email. I would have solved this
issue ​had I had direct internet connection. Unfortunately for me the only
connections I have had access to lately is "wifi" via coffee houses! I plan
to get with a direct connection so that I could access to updates! If I
have any more trouble I'll send you an email.

Thanks,

On Tue, Nov 5, 2013 at 7:24 PM, Mathieu Trudel-Lapierre <
<email address hidden>> wrote:

> ** Description changed:
>
> [Impact]
> IPv6 is becoming increasingly popular and installations on IPv6-ready
> networks are becoming more frequent; this issue affects installations of
> the Desktop image from the alternate image (or using d-i in any other way)
> when IPv6 autoconfiguration or DHCPv6 is used. These installations will
> fail to recognize that the interface should be managed by NetworkManager
> after the installation because only the "iface X inet dhcp" line would be
> commented out, leaving another valid "iface X" line for "inet6" causing
> NetworkManager to ignore the device. The solution was to comment out all
> lines in /etc/network/interfaces pertaining to interface X: "auto X",
> "iface X inet", and "iface X inet6".
> -
>
> [Test Case]
> 1a) With IPv6 autoconfiguration (for example, using radvd) or DHCPv6
> available on the network:
> 1b) With no IPv6 available on the network:
> 2) Install Ubuntu from the alternate CD; or using d-i via a netboot
> image.
> 3) After the installation:
> - a) Verify that NetworkManager properly handles all interfaces.
> - b) Verify that the network interfaces configuration is commented out in
> /etc/network/interfaces.
> -
> + a) Verify that NetworkManager properly handles all interfaces.
> + b) Verify that the network interfaces configuration is commented out in
> /etc/network/interfaces.
>
> [Regression Potential]
> Untypical configurations may find devices that should be ignored by
> NetworkManager to be handled by it. Standard installations could fail to
> comment the necessary information from /etc/network/interfaces to allow for
> NetworkManager to do is job; or the file could be mangled to remove the
> "lo" interface, which would make unrelated services fail.
>
> ---
>
> To reproduce:
> - - Download ubuntu-12.04-alternate-amd64.iso, sha256sum:
> f8d54df0afbab6a6248f6e2bcab3e68f01c04d52b0bb1f889d880ad3bc881ccb
> + - Download ubuntu-12.04-alternate-amd64.iso
> - Burn it to a USB flash drive from a completely up-to-date Ubuntu 10.04
> LTS with UNetbootin
> - Install on a machine with both IPv4 and IPv6 connectivity
> - Log in to the newly installed system
>
> Current behaviour:
> - There is no IPv4 connectivity
> - NetworkManager doesn't show the wired interface in its dropdown
>
> Expected behaviour:
> - There is IPv4 connectivity
> - NetworkManager does show the wired interface in its dropdown
>
> Thoughts:
> I suspect this is because during the install my /etc/network/interfaces
> was created like so:
> ---BEGINS---
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers