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

Bug #156720 reported by Colin Watson on 2007-10-24
26
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Medium
Matthias Klose
Gutsy
Medium
Matthias Klose

Bug Description

The following changes:

glibc (2.5-0ubuntu14) feisty; urgency=low

  * Twiddle the diff a little so it actually applies.

 -- Tollef Fog Heen <email address hidden> Tue, 3 Apr 2007 21:34:51 +0200

glibc (2.5-0ubuntu13) feisty; urgency=low

  * debian/patches/any/local-ipv6-sanity.diff: Only do AAAA lookups if we
    have an interface with better than link-local addresses available.

 -- Tollef Fog Heen <email address hidden> Tue, 3 Apr 2007 14:11:26 +0200

... are missing from the glibc package in Gutsy, and were apparently lost when we merged from Debian at the beginning of the Gutsy cycle. This causes lookups to regress to their old behaviour of hanging for users behind networks that don't support IPv6 but also don't reject AAAA lookups in a timely fashion.

This is a serious regression, and needs to be corrected in gutsy-updates. It should be a simple matter of merging this patch back in:

  http://patches.ubuntu.com/by-release/atomic/ubuntu/g/glibc/glibc_2.5-0ubuntu14.patch

Matthias Klose (doko) on 2007-10-24
Changed in glibc:
assignee: nobody → doko
importance: Undecided → Medium
status: New → Confirmed
Matthias Klose (doko) wrote :

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

Changed in glibc:
assignee: nobody → doko
importance: Undecided → Medium
milestone: none → gutsy-updates
status: New → In Progress
status: Confirmed → Fix Released
Matthias Klose (doko) wrote :
Martin Pitt (pitti) wrote :

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

Changed in glibc:
status: In Progress → Fix Committed
Tollef Fog Heen (tfheen) wrote :
Download full text (3.7 KiB)

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

Read more...

Martin Pitt (pitti) wrote :

Copied to gutsy-updates.

Changed in glibc:
status: Fix Committed → Fix Released

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.

Matt Zimmerman (mdz) wrote :

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.

Cedric (lrxzt4zsam) wrote :
Download full text (3.2 KiB)

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

Read more...

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

nicojones (jones-nico) wrote :

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 ?

Martin Pitt (pitti) wrote :

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

nicojones (jones-nico) wrote :

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

Martin Pitt (pitti) wrote :

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

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

Duplicates of this bug

Other bug subscribers