IPv6 link-local interface lookup fix regressed from Feisty to Gutsy

glibc (2.6.1-6ubuntu2) hardy; urgency=low

  * Reapply any/local-ipv6-sanity.diff, lost when merging 2.6. LP: #156720.

 -- Matthias Klose <email address hidden> Wed, 24 Oct 2007 18:15:43 +0200

Thanks Matthias, accepted into gutsy-proposed. Please test.

Short summary: Package in -proposed works for me and the fix looks like it is working.

Test method:

tcpdump -i eth1 -n port 53 in one terminal while using wget to download in another terminal.

Using:
ii libc6 2.6.1-1ubuntu9 GNU C Library: Shared libraries

: tfheen@thosu ~ > ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 fe80::20e:35ff:fe5a:faf7/64 scope link
       valid_lft forever preferred_lft forever
: tfheen@thosu ~ > wget -q -O /dev/null http://err.no/

Generates the following DNS traffic:
16:10:09.176402 IP 10.5.0.215.33158 > 10.0.0.3.53: 632+ AAAA? err.no. (24)
16:10:09.254011 IP 10.0.0.3.53 > 10.5.0.215.33158: 632 0/1/0 (81)
16:10:09.254201 IP 10.5.0.215.33158 > 10.0.0.3.53: 12036+ AAAA? err.no. (24)
16:10:09.257182 IP 10.0.0.3.53 > 10.5.0.215.33158: 12036 0/1/0 (81)
16:10:09.257497 IP 10.5.0.215.33158 > 10.0.0.3.53: 15831+ A? err.no. (24)
16:10:09.280224 IP 10.0.0.3.53 > 10.5.0.215.33158: 15831 1/3/3 A 85.19.200.177 (159)

: tfheen@thosu ~ > sudo ip -6 addr add 2001:700::1 scope global dev eth1
: tfheen@thosu ~ > ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 2001:700::1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:35ff:fe5a:faf7/64 scope link
       valid_lft forever preferred_lft forever
: tfheen@thosu ~ > wget -q -O /dev/null http://err.no/

Generates the following DNS traffic:
16:10:20.134376 IP 10.5.0.215.33158 > 10.0.0.3.53: 12500+ AAAA? err.no. (24)
16:10:20.137708 IP 10.0.0.3.53 > 10.5.0.215.33158: 12500 0/1/0 (81)
16:10:20.138100 IP 10.5.0.215.33158 > 10.0.0.3.53: 2276+ AAAA? err.no. (24)
16:10:20.140715 IP 10.0.0.3.53 > 10.5.0.215.33158: 2276 0/1/0 (81)
16:10:20.146271 IP 10.5.0.215.33158 > 10.0.0.3.53: 60280+ A? err.no. (24)
16:10:20.151414 IP 10.0.0.3.53 > 10.5.0.215.33158: 60280 1/3/3 A 85.19.200.177 (159)

Using:
ii libc6 2.6.1-1ubuntu10 GNU C Library: Shared libraries

: tfheen@thosu ~ > ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 fe80::20e:35ff:fe5a:faf7/64 scope link
       valid_lft forever preferred_lft forever
: tfheen@thosu ~ > wget -q -O /dev/null http://err.no/

gives DNS traffic:

16:16:26.700719 IP 10.5.0.215.33158 > 10.0.0.3.53: 20319+ A? err.no. (24)
16:16:26.706644 IP 10.0.0.3.53 > 10.5.0.215.33158: 20319 1/3/3 A 85.19.200.177 (159)

: tfheen@thosu ~ > sudo ip -6 addr add 2001:700::1 scope global dev eth1
: tfheen@thosu ~ > ip -6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
    inet6 2001:700::1/128 scope global tentative
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:35ff:fe5a:faf7/64 scope link
       valid_lft forever preferred_lft forever
: tfheen@thosu ...

Copied to gutsy-updates.

This patch needs to be distributed more widely than just gutsy-updates. The Gutsy Gibbon disks need to be remastered including this patch.

The bug causes installations on extremely common networks to be unable to use the network both from the live cd during or before installation, and after the installation is complete. It prevents update manager from downloading the update that fixes it (although for some reason update manager downloads the list of updates correctly). It prevents the installer from using launchpad and other internet resources to find out about the problem and work around it, either by disabling ipv6 or acquiring the patch through other means.

This bug also prevents anyone aware of the problem from recommending installing Ubuntu to others: Should one recommend just waiting for Humble Hedgehog, installing Feisty Fawn and experiencing an extra upgrade (will an upgrade from Feisty include this patch right now?), or installing Gutsy Gibbon along with caveats and a couple of pages of difficult extra instructions?

This bug demands a patched re-release of the installation media.

My understanding is that while the user experience is unfortunate (a long timeout), DNS lookups do in fact succeed after the delay. This means that it does not prevent updates from being downloaded.

In answer to your question, yes, upgrades from Ubuntu 7.04 will automatically include this fix.

On a fresh install this morning I got no response and eventually came back into the room and saw a "failed to fetch...". I downgraded the same computer back to the -ubuntu9 libc6 packages and used update manager to download patches again a few times. The first two times it started grabbing all the packages instantly. I stopped these downloads right away; I assume they would have worked.

The third time it took about 3 minutes of lookup for each package, even though they are only fetched from a handful of domains (us.archive.ubuntu.com and security.ubuntu.com). During this time Update Manager spends most of the time showing "Download rate: unknown". After it finished (last 2 packages failed) I got the message:
Some of the packages could not be retrieved from the server(s).
Do you want to continue, ignoring these packages?

The errors this time were:
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/g/gnome-system-monitor/gnome-system-monitor_2.20.1-0ubuntu1_i386.deb
  Could not connect to us.archive.ubuntu.com:80 (1.0.0.0), connection timed out

W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/u/ubufox/ubufox_0.4~beta1-0ubuntu4_all.deb
  Could not connect to us.archive.ubuntu.com:80 (1.0.0.0), connection timed out

The fourth time everything failed, with packages failing every couple of minutes, simultaneously for us... and security... The entire time the download window shows (if the individual progress isn't open) "Downloading file 1 of 25" "Download rate: unknown". After somewhere between forty minutes and an hour I got:

An error occured
The following details are provided:

[The rest of the error message is attached; it's just failed to fetch from 1.0.0.0 for every package]

A fifth attempt resulted in everything downloading again.

It's interesting how streaky the results are. It failed for everything this morning, succeeded for the first couple dozen packages of testing this afternoon, and then failed for the next 27 packages in a row, then later this afternoon succeeded for all 25 packages. This wasn't due to network issues; firefox with ipv6 disabled worked on the same computer during the same time period.

For an individual packaged downloading it has three different behaviours: download instantly, time-out and download successfully, and time-out and fail / never download.

All together this is a very unpleasant user experience. It does not just take a long time to get the upgrades to fix the problem, in a third of my experience it failed to get any of the upgrades, and the behaviour previously mentioned, "(a long timeout), DNS lookups do in fact succeed after the delay. This means that it does not prevent updates from being downloaded", being the least common result in my rather limited experience and still didn't result in a complete set of patches.

I would describe this situation as being: Major feature (all dns resolved networking) broken after install, security feature (security updates) broken after install. Even with 50% or better of installations fixing themselves on the first upgrade, and maybe 100% fixing themselves with a persistently upgrading user who has faith that the upgrades will solv...

On Wed, Nov 07, 2007 at 10:17:04PM -0000, Cedric Shock wrote:
> I would describe this situation as being: Major feature (all dns
> resolved networking) broken after install, security feature (security
> updates) broken after install. Even with 50% or better of installations
> fixing themselves on the first upgrade, and maybe 100% fixing themselves
> with a persistently upgrading user who has faith that the upgrades will
> solve his or her problem this is still a major problem present after
> installing the system.

Thanks for your analysis. As this problem has already been fixed in an
update, if there is a problem with downloading updates when affected by this
bug, the most appropriate course of action at this point would be to post an
official workaround explaining how to download the update in this case.
This will provide anyone affected with an immediate solution.

Colin, would you arrange that?

--
 - mdz

On Wed, Nov 07, 2007 at 10:17:04PM -0000, Cedric Shock wrote:
> I would describe this situation as being: Major feature (all dns
> resolved networking) broken after install, security feature (security
> updates) broken after install. Even with 50% or better of installations
> fixing themselves on the first upgrade, and maybe 100% fixing themselves
> with a persistently upgrading user who has faith that the upgrades will
> solve his or her problem this is still a major problem present after
> installing the system.

>Thanks for your analysis. As this problem has already been fixed in an
>update, if there is a problem with downloading updates when affected by this
>bug, the most appropriate course of action at this point would be to post an
>official workaround explaining how to download the update in this case.
>This will provide anyone affected with an immediate solution.

>Colin, would you arrange that?

hmm, im wondering if the problem has been fixed why is a fresh install
of gutsy from a fresh d/l off a mirror still have this bug ?

people everywhere are still having problems ?

talk about a bad taste in the mouth with ubuntu, when i saw that gutsy
integrated openssh, samba, and the other new features, i thought it was great
then i installed it and have had 3 days of nothing but problems, after gutsy installation
DNS is broken on the entire network, workstations with static outside ISP DNS
stop working complete.. i would think this would be considered a major bug.

i can ping outside ip's from the gutsy box but no name resolution even with an outside DNS
ive just finished redoing the install this morning at 5am, with raid1 and raid5, when the gutsy
box boots the DSL router / outside DNS and the entire network gets hosed, after enabling ipv6
on the router i was able to get outside DNS to work on ms workstations but gutsy still doesnt
resolve names.

is this going to be fixed ? or should i go back to slackware ?

Hi Nico,

nicojones [2007-12-06 16:27 -0000]:
> is this going to be fixed ? or should i go back to slackware ?

It has been fixed some time ago in gutsy-updates. Please update your
system after a fresh installation.

Martin

why not add the patch to the distro ? and save a bunch of people a whole lot of trouble ?

my internal network is fixed, but i think this bug broke the isp's DNS. :(

its lagged and with packet loss, good thing i have my own server. sheesh

problems solved thanks...

Hi,

nicojones [2007-12-07 0:33 -0000]:
> why not add the patch to the distro ? and save a bunch of people a whole
> lot of trouble ?

But gutsy-updates *is* the distro. It's enabled by default, and
update-notifier will point out that there are upgrades, and install
them with two clicks.

Martin