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

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

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

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.

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.

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?)

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 ;)

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.

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!

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.

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

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?

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"?

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.

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.

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.

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).

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).

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.

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

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.

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

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
...