Bug Description

In Karmic, DNS lookups take a very long time with some routers, because glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no (non-loopback) IPv6 interfaces configured. Routers which do not repond to this cause the lookup to take 20 seconds (until the IPv6 query times out).

*** PLEASE DO NOT COMMENT ON THIS BUG unless you have something constructive to say. Everything that can be said has already been said, and if you comment, you are just adding noise. Please let those that actually know what they are doing concentrate on fixing this bug from now on. ***

If disabling IPv6 or using good DNS servers like openDNS fixes the problem, you are not dealing with this bug. Please refrain from complaining here in that case

I've been struggling with this bug as well, for me it started with updates I installed on 3rd sept even though I had no problems like this in karmic earlier (at this point I installed updates from about two weeks back though). It affects all network apps (not just browsers). I originally filed a ticket with my ISP because I thought it was their DNS servers that were slow.

This problem will occur for any DNS request which the DNS resolver does not support.
The proper solution is to fix the DNS resolver.

What happens:
- Program is IPv6 enabled.
- When it looks up a hostname, getaddrinfo() asks first for a AAAA record
- the DNS resolver sees the request for the AAAA record, goes "uhmmm I dunno what it is, lets throw it away"
- DNS client (getaddrinfo() in libc) waits for a response..... has to time out as there is no response. (THIS IS THE DELAY)
- No records received yet, thus getaddrinfo() goes for a the A record request. This works.
- Program gets the A records and uses those.

This does NOT only affect IPv6 (AAAA) records, it also affects any other DNS record that the resolver does not support.
Generally these resolvers are embedded into the "NAT boxes" that consumers have.

Working solution, as we are on Linux anyway: don't use the DNS resolver in the NAT box, but install eg pdns-recursor and use that.

I'm not convinced, that this is a resolver bug. I'm running an IPv6 enabled system (aiccu tunnel with sixxs.net), so all IPv6 requests are answered by an IPv6 enabled DNS server. I'm still experiencing the same problems. Additional to that, this bug was introduced by Karmic and didn't happen before.

The 5 second lag occurs with the Livebox (used by Orange, 12 million broadband internet customers in Europe). Better fix this unless you want a number of users to tweak their config files to either disable ipv6 or disable box-based dns server, not something anybody enjoys doing.

@ Markus's #8 comment: as I mentioned "Note that the DNS queries go over IPv4 (transport), there is no IPv6 _connectivity_ involved here.".

You also state 'so all IPv6 requests are answered by an IPv6 enabled DNS server."; well, unless you configured IPv6 DNS resolver addresses in your /etc/resolv.conf then queries will still go over IPv4 (transport), even though they are AAAA queries. AICCU only provides IPv6 connectivity (transport) it does not configure DNS resolvers though.

@ Bernard's #9 comment: most likely your livebox contains one of these broken DNS resolvers. Happens a lot that CPEs have this issue. Try the below to check this out. Configuring resolv.conf with OpenDNS or other working DNS servers (eg the ones of your ISP directly, instead of the livebox) might solve your problem. Do also please realize that this problem ALSO occurs on other platforms than Linux, eg Windows, which is what the majority of people are using; what to use is a choice of the user afterall....

This should return quite quickly, even though no AAAA records for www.microsoft.com exist yet. Now, if you have a broken resolver somewhere along the way, these requests won't return quickly (unless they are locally or on-path cached as negative).

I have had the same problem, affecting all network activities. Particularly a problem when performing upgrades via aptitude. Problem completely solved by specifying Opendns as my DNS servers. I do not have this problem when running Jaunty, XP or Vista.

That's a "fix" in Firefox, but the problem still exists in every other network app (evolution, aptitude, etc.)
So web browsing (which is what most users are doing anyway) is normal speed but everything else is behaving like you have dial-up.
After the final release, if the bug isn't fixed in every app people might start complaining to their isp or even drop ubuntu (or not upgrade to Karmic)

For everybody not reading the other comments, #7 actually explains what goes on....

Yes, indeed, probably the best solution is to use just install a local DNS resolver (pdns-resolver), which hits the roots/gtld's etc itself. This is not very friendly to the general Internet, but heck, with the largest DNS server doing short TTLs and based on geography it might not matter too much.

Thus kids, "apt-get install pdns-recursor" and edit your /etc/resolv.conf to point to 127.0.0.1 when you get hit by this issue.

I agree that this bug should be considered release critical, if not just applying the workaround. What could be added to network-manager is a feature for when you connect it tries to obtain an ipv6 dns and if it succeeds, it uses the network dns resolver or if it fails then it uses pdns-resolver (I just don't think that would work for this release, maybe in Lucid)

I have had a privoxy go-slow - several seconds on every lookup - since installing Karmic beta. Hadn't really noticed a problem in any other app but web browsing did sometimes feel sluggish.

In a brainwave just now I have tried disabling ipv6 (using grub method) and now privoxy is working beautifully. I have also noticed that web browsing feels snappier generally, so I think this was slowing -all- of my apps down by a large enough fraction for me to feel the difference now.

Just to reiterate: it's repeatable for me with privoxy. IPV6 on - privoxy massive latency. IPV6 off - privoxy works fine.

I have a Draytek so blaming the router isn't practical - these have a MASSIVE installed base. Whether it's strictly the router's fault or not, it would not be ubuntu of Ubuntu to get all academically correct about it, we need some sort of workaround that can be achieved by clicking buttons.

To be honest, only the advanced users would want IPv6 anyway, so why not have it off by default and make it very easy to switch on?

> You can't tell your grandmother to edit some config files because her internet is slow

Does your grandmother use Ubuntu then? If so, then just help her out in fixing the issue :)

@ Zack Evans / #23

> I have a Draytek so blaming the router isn't practical - these have a MASSIVE installed base

This problem also is in effect when the user has Windows and IPv6 enabled on that. The problem lies in the DNS resolver (which might not be the NAT box (what you call "router") but might be even your ISP, and thus you can avoid the problem by not using the DNS resolver in the NAT box. You might of course also try to upgrade your router, maybe they fixed the problem (you upgrade your Ubuntu and other things too, because they have issues, thus try that)

> To be honest, only the advanced users would want IPv6 anyway, so why not have it off by default and make it very easy to switch on?

Because in a few years or so you will have to enable IPv6 as there won't be any new hosts with IPv4 addresses. As such, better bite the apple today and fix those IPv6 issues, then wait till you really need it.

@ camper365 / #24

yes, that is correct, as when you ping www.google.com it has to lookup the hostname in DNS, while if you ping the address, it doesn't. DNS resolving (thus figuring out which address belongs to the requested hostname) is where the problem lies. See the hints about OpenDNS or pdns-recursor to solve it.

@ Ragnarel / #25

as per comment #11 try a:
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com AAAA; done
when connected to wireless and when not connected to wireless. Or just for that matter, check if you are using the same nameservers when connected to wireless and wired, if they are different then you already got a small part of the answer.

Is it possible, that some patch changed the usage order of the nameserver from /etc/resolv.conf?

My router does deliver a "dead" nameserver via DHCP [1], which was never a problem since Ubuntu used to question the first (local) nameserver. The local nameserver resolves any given request without a problem [2]. If I remove the dead nameserver from resolv.conf, I no longer have any problems resolving DNS queries.

So it *might* be a solution to just change the usage order of the DNS servers to solve this "bug". Please notice, that a lot of users never experienced this problem before Karmic, so it might be hard to blame their hardware for this, even if it might be technically true... :-)

Is very quick though. I consistently have slow resolution when running updates, but the same command against archive.ubuntu.com is also very quick.

The router has something to do with it I'm sure, my router at home doesn't give me any trouble at all, but querying so directly like this is reproducibly fast, while querying indirectly through update-manager, is reproducibly slow.

What that does is avoid fixing the problem. You disable IPv6, and thus glibc plays smart and does not resolve AAAA records anymore.

Your DNS resolver though is still broken. You might not notice it now, but if for instance per next year DNSSEC gets turned on you will run into it again.... (and you will probably just disable DNSSEC....)

2009/10/21 Jeroen Massar <email address hidden>:
> @ csulok / #32
>
> What that does is avoid fixing the problem. You disable IPv6, and thus
> glibc plays smart and does not resolve AAAA records anymore.
>
> Your DNS resolver though is still broken. You might not notice it now,
> but if for instance per next year DNSSEC gets turned on you will run
> into it again.... (and you will probably just disable DNSSEC....)
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I think the problem is not DNS. Actually, when I visit different websites in a short period of time, then everything get saturated. Some websites not load, and other take up to 2 or 3 minutes to do so. I tried it using Google Chromium also, and the result was the same. Is a new instalation the karmic, and the upgrade just happened

As you have the same DNS server for both wired and wireless, most very likely _your problem_ is not a DNS issue* like what the others show here.

* = unless an upstream of your DNS server has the "drop unknown DNS records" problem and your resolver caches the negative answer correctly, which will cause any subsequent query, like the ones above, to be quick again.

To solve your problem, I guess you'll have to take a peek with Wireshark...

I quickly looked at the Privoxy 3.0.12 IPv6-patch included in Debian (and probably the same thing in Ubuntu) and it seems that it is quite incomplete and has quite a number of broken assumptions. One of the primary brokeness is actually documented in the patch with: /* TODO: Allow multihomed hostnames */ indeed, that also means that if a host has multiple A and/or AAAA records, it will only try to use the first one, which might actually be an IPv6 address (which is generally preferred). As an example www.google.com has generally 4 IPv4 IP addresses (A records) and as that Privoxy patch only supports 1 address per hostname, it will only use one of those. If that single address is then IPv6, it will try IPv6.

If your IPv6 connectivity is then broken (which might also be the problem for other hosts) then of course it will take quite some time for that to timeout....

I would say: file a bug report against privoxy as clearly the patch that is included can various websites which have multiple addresses to only have the use of one address. and of course only IPv6 or IPv4 is then supported by it... in other words: BROKEN.

With the above in mind, people who have problems with "IPv6" should perform two tests:
- ip ro sho |grep default
^---- if you have a default route somewhere then of course it will be used, thus check where it goes and if that makes sense for you.
- for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com AAAA; done
^-- if this has huge latency then your DNS resolver (or one above it) is broken. Do test this also with different hostnames then just www.microsoft.com, try especially hostnames that you didn't check in a while as they might be cached somewhere.

I've also been hit by this bug on a new Karmic install. Had no problems with Jaunty on the same hardware.

Tried csulok's work-around from post #32, which didn't work. Disabling IPV6 in Firefox does work (but only for Firefox, of course). Changing my IPV4 settings to use Open DNS works universally, but seems like a rather unpleasant kludge to use as a permanent fix.

I am surprised that this isn't release critical. Probably the biggest reason people get on the computer is to use the internet and if people associate Ubuntu with slow internet, no matter how fast you make it boot, they won't want to use it. Even if it is just a workaround that is applied to the final release, it still should be done.

I have not used launchpad before and am not sure of the procedures. This bug has been nominated as a confirmed and high bug in the Network Manager but has not been confirmed or assigned an urgency under Linux (Ubuntu). This means it does not appear as a high urgency problem when you search the bugs for Karmic which I would have expected it to. Could it be that this problem is getting overlooked?

Post #30 directions seems to be the common advice given to fix the issue and fixed it for me (thanks Dodge V83). Still I agree this a major problem and Notwork Manager is the biggest pile of crap software that comes with gnome and I have no idea why they don't toss the shiiteware out like they should. A much better alternative I hear is wicd. To install type

Ack don't use wicd if you have a netbook and use the ath5k driver (still very beta nice way to put it) as suspend and resume hose up the ath5k driver (pretty sure Network Manager handles this by doing an rmmod and modprobe). These network issues are precisely why Windows is owning Linux on the netbooks. I got mine running fine but not everyone has a CS degree. Most people just want it to work out of the box. Oh well maybe next version.

Next version? This should have delayed the release at least long enough for ipv6 not to be seeded on the LiveCD. People may consider the slow internet on the livecd to be caused by the fact that you're running from a cd, but when they install it they expect it to be full speed, which should be faster than Windows. I know that ipv6 needs to replace ipv4 soon, but if trying to do it slows down the internet, and Windows isn't doing the same thing, then it is considered an Ubuntu problem and not an isp or DNS resolver problem (whether it is or not). A lot of people are willing to take any fault with Linux to an extreme and say that is why you shouldn't use it (even if it isn't true). This will make people like that go nuts because they have found a problem with Ubuntu that isn't in Windows, completely disregarding all of the problems in Windows that aren't in Ubuntu. I have not seen Windows 7, but I have heard that it is a lot to compete against and if Ubuntu has slow internet, people won't even bother looking at it. You can't say that a fix is to go this bug report and look at comment #30. If there is a workaround, it should be applied before it is installed.

I agree it is a pretty serious issue for many and by no way mean to imply windows is anything but a well polished turd. All in all the upgrade to 9.10 on my netbook (Samsung NC10) was largely seemless (a few minor issues including this one that took maybe an hour to resolve but again I am a tech geek that loves the command line) and is much snappier than any windows as well as even 9.04. But for Joe Q Public this issue would be a showstopper. I agree this needs to be resolved asap as networking is always one of those issues that scare non techies (and with crappy drivers like ath5k and imho not so good Network Manager they should be scared). We are on the same page.

I too am surprised this did not block the release. Can we appeal to a higher power? I'm not too familiar with the development process of Ubuntu but surely there's some IRC channel or mailing list where we can get the attention of somebody with "connections".

i'm adding this comment, because it might help some who think that they problem with the connection is related to this ipv6 bug (i thought the same)

on my laptop, the ethernet card picked up the connection to the local router, but browsing didn't work. (but it opened google pages as is realized later)
wifi connection was fine, with browsing and everything
i tried every workaround in this thread, but none of them worked

I seem to be suffering from the same problem. On my desktop with wired ethernet connection I seem to have a problem with DNS:
- I get a timeout when I ping a host, e.g. ping google.com
- I cannot resolve the address when I do host google.com
- I can resolve the address when I do host google.com ip_of_my_dns
- the info field of the network-manager reports the correct dns servers
- it works as expected after I have restarted network-manager

I have no problems on my laptop which is connected wirelessly to the same router and thus is using the same settings.

This bug affects me too but I found a simple work around. Edit your settings in network manager and put your routers IP address as the last one in the DNS servers box. Find your providers primary and secondary DNS server IP addresses and ensure they are listed first. Once you make the change you need to disable networking and then re enable it for the change to take effect. Browsing is speedy now! I hope this helps everyone get going for now but I also hope the bug gets fixed because there is no reason your router should not be able to be listed first.

Of course it fixes the problem, this as the problem lies in the DNS resolver that is inside the DSL/cable/etc modem.

Thus by entering/using OTHER dns servers, preferably the ones from your ISP, otherwise the ones from the OpenDNS or similar providers, you bypass the DNS resolver in the modem, and thus the device that would otherwise drop DNS queries for AAAA records.

I do not think the problem is with the DNS resolver in the modem because other PC's do not have this problem and this PC did not have the problem until an upgrade to Karmic. I think the problem is how Karmic interacts with the modem.

Just try the following: dig @<dns server that is broken> www.bingabongobango.com AAAA

That will take quite a long time to return.

The problem is that when you install Karmic, you get IPv6, because of that, programs that are IPv6-capable will start asking for AAAA records As the DNS Server is broken it will not reply to the request. Thus it looks like things are slow.

If the other PCs are using that DNS server, but not asking for AAAA records, then all will be fine and you won't notice the slowness indeed.

This allowed me to use aptitude to download software and updates. This is the easiest solution for joe user and grandmothers to get started with Karmic without editing conf files. Eventually, there may be a better and more permanent solution for all users.

Joeren: Well, my suggestion was to *switch* the nameserver entries, not to replace them. I already suspected that Karmic changed the order of the DNS requests, in fact asking the last nameserver in /etc/resolv.conf first, while Jaunty asks the first nameserver.

While changing the order again wouldn't solve any problem here, but people with a single broken DNS server wouldn't notice the change as a regression, since it worked for them in Jaunty and it might still work for them with Windows.

I disabled ipv6 in firefox, and lspci indicates ipv6 is turned off in
karmic. The problem still persists in the case that I'm using a linksys
router as the DNS relay. If the router is removed from the DNS list,
everything speeds up.

Before anyone tells me to get a new router, this problem didn't occur in
Jaunty, just Karmic, and I've done everything possible to confirm that
IPV6 is disabled on my machine. So it's one of two things:

1) Karmic uses a different library than Jaunty to do DNS lookups, and
that library has introduced some kind of bug (I'm guessing it's a
sequence of queries, not just one since it takes a few minutes of very
slow surfing before the router gives up entirely)

2) Karmic is lying about ipv6 being disabled and is insisting on using
it anyway.

I attempted to report this as a separate bug because I completely
eliminated IPV6 from being the culprit, but here we are.

I have the same problem with 2 desktops and a laptop. I've tried the laptop wirelessly on 3 different networks and the severe slowdown continues. The workaround below fixes the slowdown by disabling IPv6 on bootup (it's worked on all 3 computers):

start a Terminal session and type:

gksu gedit /etc/default/grub ....then change

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"

then

sudo update-grub

Reboot and network speed should be back to normal.

I hope that a fix for this disconcerting bug is provided ASAP. Thanks.

@jorden.sc: I had already done this manually in menu.lst, I now also tried the above - but even though I let update-grub even generate a new menu.lst, the ipv6 param is missing!!!!
I had to add it manually again.

Also, disabling ipv6 this way does solve my firefox DNS problem (I reenabled ipv6 in the firefox prefs), BUT my Ruby on Rails (2.3.4) plus apache and passenger development environment now takes MUCH longer to respond than before. Now my normally much slower laptop (with an identical dev. environment) suddenly is much faster than my PC. Some network lib is still causing a pause before each request - and it is not the apache/passenger side.

It is my mysql connection!! How do I know: On my laptop the vmware-internal network host-only network did not work any longer after the 9.10 upgrade. So I moved the mysql server from the laptop's Windows into the Ubuntu inside Vmware and gave it some more RAM. It now works as before. On my PC - also running Windows and Ubuntu inside VMware - I left the database on Windows and Rails connects over the network, there I don't use host-only networking (the "global" network adapter is always on, unlike on the laptop where I often work without offline any network attached to the laptop).

When I test this command :
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com AAAA; done
The response is instantaneous. But when I do this lookup :
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.speakeasy.net AAAA; done
This is very slow, and the delay is there.
Notice that I have no IPv6 connectivity, and that the IPv6 stack is activated, as the default.
This is the delay that we are talking about. And I think this is a misbehaviour from the involved authoritative DNS servers :http://www.ietf.org/rfc/rfc4074.txt
The explanation is that the DNs server should return an error when there is no AAA record. But in this case it returns nothing. It doesn't follow the RFC. So the resolver wait for the answer, and then time out.
I think that the fact of changing one DNS server to another resolved the problem is due to the fact that the newly configured DNS servers does cache the "no response" state", or something like that. Just a thought. Don't know enough sfuss about it.

One solution is to wait for the involved DNS to update and support AAA records. But it may happen in years.
Another solution is : Disable AAA address resolution when there is no IPv6 routable address configured on any interface, or when Network manager has his IPv6 parameters set to "ignore" (which is the default in Karmic, and is a new feature that is not present in Jaunty ). The getaddrinfo() function is the one that should not ask for AAAA records when there is no IPv6 connectivity.
It seems that the Red hat team has already encountered this problem :http://kbase.redhat.com/faq/docs/DOC-17904

The wrapper library seems to be a solution for that. What do you think of all this ?

A couple of ways to accomplish this:
- use your ISP DNS servers directly
- use OpenDNS or a similar provider
- local caching resolver: put 127.0.0.1 as the nameserver (/etc/resolv.conf) and install pdns-recursor

The latter can be done per default in Ubuntu and would always work and require no setting changes.
The only negative side-effect is that the caching effect of DNS might be less used, but then again, most sites use DNS loadbalancing now, thus this is a non-issue.

@rsoulliere thank you very much, your link in #66 solved this issue for me.

Personally I regret trying to upgrade to Karmic. I had a severe bug in Jaunty that freezed my system once a day. When I upgraded to Karmic my system began to be unbootable because of an sergv in mountall. When I reinstalled I had no net :/

For those that say that the problem is in the way routes and some dns servers handle ip6:
So Karmic was released to show use how bad network equipment we bought ? to teach us a lesson ?

This bug should be a show stopper, at least for the feature change caused it. Ubuntu is becoming more unusable release after release. I'll try to do more beta and alpha tests my self in the future but I can see here beta testers comments didn't help.

@cosmo #76, of course it is "just" a work around. The problem lies in your DSL/cable modem, not in Ubuntu. Thus ubuntu can only work around this issue. You didn't see the issue before as you where not using all the features of the Internet (IPv6 ;)

@Jeroen Massar #78: You wrote "the problem lies in your DSL/cable modem, not in Ubuntu". I'd like to make a few points.

1) No IPv6 slowdowns in Jaunty or Mint 7 (which both have IPv6 enabled) anywhere I've tried. Which "features" of the internet am I not using in Jaunty but am using in Karmic?

2) Serious slowdowns with Karmic at a local coffeehouse, my place of business and the airport where I have no control over their modems.

3) OpenDNS, etc. remove some features of Firefox such as "automatically" determining which site I'd like to go to when I type key words into the address bar. If I enter "ubuntu forums", Firefox will take me to http://ubuntuforums.org/. OpenDNS will not do that.

4) Bottom line is that this needs to be fixed/patched/whatever so that most anybody trying Ubuntu for the first time will have a good experience. Currently, for many, Ubuntu cannot provide such an experience.

This is very stupid and I should have tried it before contributing to this bug. I have been using a Belkin wireless adapter on Intrepid and Jaunty with no issues so when I upgraded to Karmic and internet was slow I didn't think it could be problem with the adapter support. Well, I'm still not sure whether that is the problem or not but, having seen that disabling IPv6 in Firefox didn't do any good, I decided to give it a try and change to a wired connection and every thing is back to normal now, fast internet access across the whole system.

Maybe it's worth a try for all of you who had this problem using wireless.

Another issue in addition to ipv6 is how the resolver-lib handles search domains. I found I could avoid the delay by removing the "domain" and "search" statements from /etc/resolv.conf. In this particular case there's a broadband-router which put either the providers domains or a configured local alternative in the DHCP-response. There's no way to make it drop the options altogether when it's not used properly. Thus a solution (in addition to a local caching resolver etc described above) is to remove these options (domain-name and domain-search) from the list of options the dhcp-client (/etc/dhcp3/dhclient.conf) asks for. This problem is easily identified as described in #82 above.

Wrt #84, is it a correct observation that the resolver-library in karmic always tries to add search-domains to the queried string even when the original query from the application is for a FQDN? The first DNS-request from a karmic client looking for "www.google.com" in a browser is for "www.google.com.localdomain" when "domain" or "search" is specified in /etc/resolv.conf. I thought the search-strings only were appended when there was no domain-part specified, and/or if there was no response/hit on the first request.

The reason for the delay described in #84 and #85 seems to be a firmware-bug in a wlan router (D-Link DIR-655). It doesn't seem to pass NXDOMAIN-responses to the clients when it is set up to relay requests. The upstream servers respond immediately with NXDOMAIN when queried directly. However, this problem wasn't discovered before so the behaviour of the client resolver has obviously changed in karmic.

Just to add to the voices being affected by this bug. Everyone in Ireland using an Eircom router (00,000's of customers) will encounter this issue. It is crazy, I logged on here to read about it and I can't believe it was pointed out weeks ago and nothing was done about it.

No point in blaming 'the router' or anything upstream. All I know is everything was fine in Hardy, everything is fine in Windows 7. Hell, if I load up a Windows XP VM in Virtualbox within Karmic, DNS lookups work flawlessly from the same router!!

In Germany it's the Router of the Provider "Alice" which has this issue. And i think it could be, that it maybe not talking in the correct standard way but it worked in Hardy and Intrepid and where is the use of forcing standard behaviour and killing functionality?

Everyone here is posting "reasons" and "workarounds" but that's not the point. That's exactly the point why all this windows-user guys say "Linux is to complicated". In an Operating System called "Ubuntu" (we all now what the name means and what it stands for) which aims to be an OS for every user it is absolutely impossible to accept "workarounds". And all this worked fine in the last versions.

@Laurent - I'm not familiar with the way confirmed Ubuntu bugs are dealt with, but since you changed the assignee to nobody, does this mean that the issue will not be addressed? And that many thousands or more of Karmic users will have the equivalent of dial-up speeds unless they are tech savvy and know how to tweak conf files or blacklist modules?

One could argue that the resolver could refrain from issuing IPv6 queries when no IPv6 connectivity is available. (I.e. just link-local addresses on the interfaces.) It might be too expensive to check this on each and every query but it would relieve the problem a bit.

Disabling IPv6 in Firefox by default is a very bad solution as we want to achieve IPv6 support out of the box. I also encountered those broken resolvers in the wild, though, and it resulted in me configuring sane DNS servers for the single Alice access point through NetworkManager, which works just fine. If there would be an anycasted DNS resolving offer out in the wild we could use that instead, but even then you usually rely on using the local DNS servers in case they give you different views in the corporate environment (to see local hosts or route requests differently).

I'll give it up... posting, confirming assigning bugs in this senseless bugtracking system with every ignorant hacker freak telling some stupid workarounds about howto edit some stupid config file. iMho A bugtracking System should keep track of bugs for people SOLVING Bugs. This one here should be called Workarounding System.

I mean i always told my Family and Friends to use Ubuntu because its EASY. Because its just WORKING unlike Windows. I told them "trhough your windows copys away you dont need them if you ever tried ubuntu".

And now? When i tell those guys aka "Users" or "Mortal" - hey the whole community knows about the Problem that your internet connection is as slow as in the early days back when you had a 56k Modem. But its ok for THEM because THEY are SELFISH and able to edit config files. And guys this is pretty important for IPV6 ???

I made the assignation to get someone to look at the PROBLEM not to disable ipv6. the should REPAIR this. So i assign it again. Will do this 1000 times more if i need to.

@cosmo et al., I reported that it also slows down my VMware host-only network communication when my laptop is without any connection to an outside network, so THERE IS NO INTERNET AND NO NAMESERVER AT ALL. Yet, I had to move mySQL from the host OS into the virtual (Ubuntu 9.10) machine in order to be able to continue working - because every single mySQL request, and there are a lot when you develop a website, took a few seconds longer than before the upgrade.

Also, I disabled IPv6 in grub (ipv6.disable=1) and while it helps Firefox (I re-enabled ipv6 in Firefox and it still worked) it did NOT help other applications: my ssh connection to a server on the Internet takes a loooooong time, but when I use "ssh -4" (tell ssh to use ipv4 only) it's immediate. AFTER I DISABLED IPV6?!

So the case is NOT as simple as some people want to make us believe, and it certainly is NOT a problem "of your router" (i.e. mine). See above.

I've been "doing Linux" since 1995, I even did kernel development (networking/firewall/network address translation) up to kernel 2.4. And I say this is a bug in Ubuntu!!! Okay, any number of exclamation marks, i.e. yelling, does not make me any more right, but... oh well.

But who cares, the only reason I'm still here is that SuSE's and Fedora's new releases are still two weeks away.

Don't assign bugs to persons or groups, it won't make anyone fix anything faster. And stop posting workarounds, the bug report should focus only on a SRU bugfix (use forums for workarounds). Only assign it to yourself if you intend to work on this bug and have the necessary skills. Many many bugs spiral out of control with rants and complaints and then the useful info gets buried and it takes longer to fix it.

The best thing you can do if you want this bug fixed faster is find someone on IRC who has got the skills to fix this bug and then post the LP url to them and explain why it's important.

This issue is serious, it affects a large percentage of the Ubuntu population and, as is obvious by this long discussion, is both a) annoying and b) hard to understand/diagnose/fix properly.

But, if you filter this conversation there is both a good diagnosis (#4) and a good, tested workaround (#74) implemented by engineers at RedHat. The one issue with the workaround is that it essentially disables IPv6 AAAA DNS record lookups when calling getadderinfo() with AF_UNSPEC.

In the README.txt of the RedHat workaround called "libwgetaddrinfo.so" you find:
"IPv6 lookup avoidance by LD_PRELOAD=libwgetaddrinfo.so. getaddrinfo will perform IPv4 and IPv6 lookups when using AF_UNSPEC." They also state that this technically breaks RFC2553 compliance, which is bad.

Right now, in the short term, we're faced with a "lesser of two evils" decision:
1. Adopt the RedHat solution and in the process break RFC2553 while fixing 100% of this problem.
2. Annoy and confuse 80-90% of the Ubuntu population by doing nothing.

Don't get me wrong, I am an IPv6 zealot, but it is counterproductive to the IPv6 cause to force people to disable/fix/workaround IPv6 by hand. That kind of deep mental scaring will end up generating negative PR (google: ipv6 sucks) which will only slow adoption.

I suggest that we adopt option #1 (the RedHat workaround) ASAP and deploy it before this becomes an even bigger firestorm (like an article in eWeek talking about Window 7's superior networking speeds). That's good for no one.

In the mean time we (that's the "royal we") should find some way to un-break the RFC2553 compliance perhaps by only enabling the workaround when the network interface is routed over a broken network (one that doesn't properly do AAAA DNS record lookups). But this will take time and some creativity and we can't afford to wait for that when there is a perfectly good solution available now.

I hope this suggestion is helpful and moves this issue toward resolution.

@JoeKlein: No it is not. It would be - if this were a Debian bugsite. However this is Ubuntu. It is getting a little tiring my friend, but I'm sure you too know who the target users of Ubuntu are vs. Debian or CentOS.

On Tue, Nov 03, 2009 at 06:39:06PM -0000, Michael Hasenstein wrote:
> Also, I disabled IPv6 in grub (ipv6.disable=1) and while it helps
> Firefox (I re-enabled ipv6 in Firefox and it still worked) it did NOT
> help other applications: my ssh connection to a server on the Internet
> takes a loooooong time, but when I use "ssh -4" (tell ssh to use ipv4
> only) it's immediate. AFTER I DISABLED IPV6?!
>
> So the case is NOT as simple as some people want to make us believe, and
> it certainly is NOT a problem "of your router" (i.e. mine). See above.

It's a problem with the nameserver on the router, not with the router
itself. If the libc does AAAA requests that are not properly answered
which it doesn't when you force it to (through -4) that's hardly the
fault of the C lib.

> I've been "doing Linux" since 1995, I even did kernel development
> (networking/firewall/network address translation) up to kernel 2.4. And
> I say this is a bug in Ubuntu!!! Okay, any number of exclamation marks,
> i.e. yelling, does not make me any more right, but... oh well.
>
> But who cares, the only reason I'm still here is that SuSE's and
> Fedora's new releases are still two weeks away.

Oh great. Rest assured that I experienced the same problem with Fedora, too.

Right now I am seriously considering switching over to Fedora or openSUSE and scrapping Ubuntu. I am perfectly able to tweak conf files and apply workarounds, but I don't want to do it every minute of every day. I have work to do other than get the system running.
It seems to me that the management and developers of Ubuntu are lazy and trying to deny the problem. The problem is there whether they are a victim of it or not.
Articles saying how slow Ubuntu networking is compared to Windows 7 is certainly not going to help the Linux community at all. I know the developers put a lot of work into this release, but it won't be much more to apply a workaround. This bug has existed for over two months and that is plenty of time to apply a workaround and potentially a fix.

So i thought that nothing changed in this since 9.04 when a lot of applications were ipv6 enabled....

The issue is that AAAA records are useful for computers which have ipv6 routes (on the internet).

So is this bug is new or valid....?. If some one can reproduce this and provide a tcpdump showing some evidence of extra look ups that would be interesting.

However, if the system does not have a valid ipv6 route i would hope that it does not try to connect to an ipv6 non-route-able host..... I know there is a problem when a *false* ipv6 route is advertised. In this case, there may be a problem. Unlike ipv4, ipv6 is not widely deployed so checking if a route is valid *may* be a good idea(throw it away if there is a known working ipv4 route). I am not sure what networking-manager does.

If there is a library waiting for the response of an ipv6 request and there is no ipv6 route.... that is an issue.

The RH workaround with a preload library isn't something that we could sensibly put into an SRU, since you'd have to preload it for every single program that does DNS resolution (and there are thousands in the archive).

Just to ensure that we are all talking about the same thing, this is what I see:

> and why not blacklisting the loading of the ipv6 module instead of replacing system functions like that?

IPv6 is built into our kernel, there are no modules. But perhaps we could modularize those in the kernel? Kernel team, does the Jaunty kernel have a different IPv6 setup than Lucid? We didn't have this problem in Jaunty, and I don't believe it's a glibc regression (since a jaunty chroot on karmic kernel has the same problem).

I strongly disagree, breaking IPv6 globally just because some people sit on broken resolvers is extremely bad. I suspect the IPv6 users group is at least as big as the one sitting on broken resolvers, and while the IPv6 group is getting larger every day the broken resolvers group should stagnate or even get smaller.

Earlier Ubuntu versions had a patched libc6 that disabled AAAA lookups for AF_UNSPEC _IF_ no global IPv6 addresses were configured on the system. This could be a way forward and would be in line what Windows is doing today.

I'm sorry, but blacklisting IPv6 is unacceptable. The 'apocalypse' is drawing near — current projections point to 2012 as the most likely date.

So it's almost certain that by 2011 the majority of Internet users will have an IPv6 connection.

And then this begs the question: will Ubuntu 10.04 systems be in production in 2012. Of *course*!

Therefore anybody with the slightest bit of common sense cannot possibly for a moment consider disabling IPv6 out-of-the-box. Having IPv6 work out-of-the-box is extremely important, despite the issues people are having now (which, to be honest, are due to broken IPv6 connectivity or broken DNS resolvers; not Ubuntu's fault, and not something we should fix).

Two very high profile OS launches around the same time. Windows 7, and Ubuntu 9.10. Plug a Windows 7 box into my router, and everything is fine. Plug an Ubuntu 9.10 box into my router, and my internet experience is dog slow. But it's ok, i'm sure the general public will understand that Ubuntu 9.10 is still superior, it's actually Windows 7 that is broken, believe it or not!

Ubuntu 8.04 and 9.04 are also "broken", so if you want a good internet experience, perhaps downgrade to one of those fine distributions

I presume the official Ubuntu solution then is not to use routers with crap DNS resolvers on them. Everyone should be petitioning their ISP to send out routers to all customers that have built in DNS resolvers that correctly support ipv6! I'm sure the ISPs will definitely want to help out here, I'm sure it won't cost them much to replace all of these routers in Germany, France, the USA, Ireland, etc.

@ Martin Pit - Excellent points and I see where the RH solution is not the
best for some obvious technical reasons (Doh! I didn't think that one
completely through, my mistake). Thanks for pointing that out to me.
@ Bernhard Schmidt - I too would like to gently move people forward, to have
ISPs and users replace "broken" equipment and to transition everyone to
IPv6. The reality is that this is a transition period and we need to deal
with a situation where we have a foot in both worlds. Clearly this
situation causes pain on both sides of the fence. The libc6 patch you
mention seems like a reasonable approach, maybe there is even a way to
improve it, and one that might get us through this intermediate stage. Once
IPv6 capable hardware is in the majority and I can call up any old ISP and
ask for IPv6 service (or better yet, not even have to make that call) then
we're past the tipping point and we don't have to keep the workaround patch
around. We're not there today.
@ Jeremy Visser - You are passionate and persuasive in your arguments. This
is not an discussion about who's at fault or how much time we have before
"the apocalypse", we need to separate passion from this discussion and move
on to fixing the problem. I'm simply trying to find a way to bring people
over to the IPv6 world without creating and equally dispassionate anti-IPv6
crowd along the way (take @ Jonzer's response as an example).

There is no need to be absolutists on this issue one way or the other.
There has to be a technical solution that lets us live in the middle
ground, lets just engineer around this and get past the political bickering.
:-)

Well when I was talking about blacklisting the ipv6 module (that is not a module anymore, but anyway) it was talking about a configuration option (like on RH system) to easily prevent the loading of the module on boot, but I was not talking about blacklisting it _by default_ (as I'm also a big IPv6 fervent too, die NAT, die!)

So, it seems that there is growing consensus for #111 if not enabled by
default. But I wonder, is there no way to detect this situation and switch
between the two behaviors automatically? What if after a few failed AAAA
lookups the code says, "Ah ha! Network interface foo is on a link which
isn't quite ready for IPv6 because AAAA requests keep timing out which must
be annoying the heck out of the user of this system by now. From now on,
requests on the foo interface will skip the AAAA record lookup and go
directly for the A record instead." Do this after requests for AAAA records
continually timeout (it won't take long to see the pattern) and requests for
A records always succeed.

Note, this is just a crazy idea off the top of my head so feel free to tell
me, "Nope, sorry. Not a good solution." But if you do, could you also
explain to me your reasoning?

Mithrandir| so I suspect somebody should take my patch, refine it so it doesn't just reject v6 addresses (try again after processing if there no hits, allowing ipv6 then, or something like that)

I confirm that in my dapper to jaunty chroots "normal" applications like wget, apt-get, firefox etc. work just fine. I was just misled to think it'd be a kernel issue because I used "host" (which also times out).

| Ah, Tollef shed some light on this. Ubuntu's glibc up to early Karmic
| had a patch applied which disabled unnecessary IPv6 DNS lookups
| (http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff).
| This was dropped in Karmic to fix some IPv6 lookup issues (bug 239701,
| bug 374674), but also caused this regressions.
|
| Mithrandir| so I suspect somebody should take my patch, refine it so it
| doesn't just reject v6 addresses (try again after processing if there no
| hits, allowing ipv6 then, or something like that)

If you want to emulate a broken DNS server (regardless of whether you
have access to one), add something like the following iptables rule:

then try to look up sixxs.net or any other second-level domain. It does
not matter whether this actually has AAAA records or not. Assuming you
don't have any IPv6 address with scope >= site, this should be slow on
9.10 and fast on 7.04 through 9.04. If you have any IPv6 address with
scope >= site, it will be slow on all variants. (The reason for the
two-level limitation is due to limitations in the u32 classifier.)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

I don't know if blacklisting / disabling ipv6 is good or bad idea and I don't really care. I only want for my browser work as it is supposed to. I know that if edit grub and disable ipv6 everything works smoothly and "clean" installation don't let me browse internet in peace.

I'm a regular internet user, not a techie like most of you. I reported this problem as bug #472586 before I stumbled across this bug report. I liked Ubuntu - before the upgrade. Now I'm screwed and can't use it, and I'm going back to Windows. Why was this upgrade released with a problem like this? For a regular person like me this is totally wrong. I had to put in a lot of time and effort to learn how to install Ubuntu, configure it, use it, etc... For every regular person who wants to try and use Ubuntu this is strong message: Ubuntu is for techies only; regular people are not invited.

* debian/patches/series: Apply any/local-ipv6-lookup.diff again to fix
painfully long timeouts on DNS resolution, if routers do not send an
answer to AAAA (IPv6) DNS queries. With this patch those DNS requests are
not sent in the first place if there are no routable IPV6 interfaces.
(LP: #417757) This reopens LP #239701, #374674, so a full solution would
need to fix the patch properly.

This should at least provide a bandaid for the people subscribed here to get sanity again.

It works well for me. However, due to reopening the other two bugs this isn't a complete solution, so the patch needs refinement.

Will anyone testing the patch mentioned in comments #121-130 please let us know how things are going? (=
Can anyone give a guesstimate as to when this patch will be released to the general public through karmic updates?
I've been trying to get my family and friends into Ubuntu, but I cannot recommend it to them until this very serious problem is resolved. I don't know anybody who would be fine to purchase a new modem/router for the sake of IPv6 in Ubuntu, at least not when everything, except Karmic, appears to be working fine. I believe no1lunchbox's comment (#127) hits the nail on the head.

In #132 SonicBOOM wrote "I don't know anybody who would be fine to purchase a new modem/router for the sake of IPv6 in Ubuntu, at least not when everything, except Karmic, appears to be working fine."

Like Bernard Bou (post #9) I am with Orange in France. I actually installed to a new Livebox last week and made sure everything was working fine in 9.04 before "upgrading" to 9.10 on three machines so even a brand new router does not help.

I realise the technically savvy posting above have put a lot of work into hacks and work-arounds but I endorse the comments in posts #14, #87, #88, #127 & #132. An average user wants things to work out of the box and 9.10 should not have been released like this. I am astounded this is not rated a "critical" bug.

Pessimistic estimates say that the problem we suspect (a DNS proxy that
cannot handle AAAA queries) affects about 0.5% of the global userbase.
50% of those can easily be fixed with a firmware upgrade of their
router, which is usually a very good idea anyway.

I'm sure there are regions with higher rates if a large provider gave
out broken systems, but generally saying that all Ubuntu 9.10
installations are affected and everyone has to purchase new routers is
pure FUD.

For the record, this bug can easily be tested with the following tools

You are only affected _if_ the first query is fast, but the second query
is very slow and/or shows something else than NOERROR in the first line
(SERVFAIL or REFUSED for example). If the DNS query is fine you should
not be affected.

@Bernhard #134 wrote
"Pessimistic estimates say that the problem we suspect (a DNS proxy that
cannot handle AAAA queries) affects about 0.5% of the global userbase.
50% of those can easily be fixed with a firmware upgrade of their
router, which is usually a very good idea anyway."

Even if a firmware upgrade of my router fixed this issue (and it did not), I cannot, nor am I authorized to do firmware upgrades at the local coffee shop, at the airport and at my place of business, all of which are locations in which the IPv6 bug slows my network connections to a crawl. My network speeds are quite fast when I use Ubuntu 9.04, PCLinuxOS 2009.2, Windows XP, Vista and 7 on my "broken" router and at the other locations I mentioned above.

Please, let's get this issue resolved within Ubuntu as none of us has the power or influence or wealth to fix all the world's "broken" routers and ISPs.

Do we actually know which routers are causing problems?
I have a Netgear WGR614v6 patched with latest firmware V2.0.19_1.0.19
Does this problem only affect a few routers that do not support IPv6, if so which ones work?
Which home routers support IPv6 at the moment? I seem to find it hard to find any. If I was to buy a new router (and it is about time) I would want it to be IPv6 enabled.

> I cannot, nor am I authorized to do firmware upgrades at the local coffee shop
> at the airport and at my place of business

And generally these locations have neutered DNS already anyway, eg they only allow HTTP/HTTPS and generally only after authenticating (after being hijacked using DNS to their portal thingy). These locations (coffeeshops, hotels, airports, other generic hotspots etc etc) don't provide true internet anyway and are thus breaking already way too much protocol wise that there is nothing you can do about it.

The only thing you can do in those locations is to VPN out if you want to resolve that problem.

In the cases where DNS requests are not blocked (like in hotels and coffeeshops), you can setup pdns-recursor and use 127.0.0.1 in your resolv.conf

@Bernhard #134 wrote
"Pessimistic estimates say that the problem we suspect (a DNS proxy that
cannot handle AAAA queries) affects about 0.5% of the global userbase.

@Bernhard #134 wrote
50% of those can easily be fixed with a firmware upgrade of their
router, which is usually a very good idea anyway."

Do you have any verifiable and opposable reference on those figures?
Where is the study that produced those "pessimistic estimates" (...)
"0.5%" (...) "50% of those"(...) ?
What was the methodology used to produced those figures?
What was the sample?
How was it picked worldwide?

This is as Jeroen and others have pointed out repeatedly, primarily an issue with broken resolvers/forwarders often part of cheap broadband/wlan routers. I just want to repeat that this isn't specific to IPv6, and emphasise that changes in karmic have made things worse.

Karmic always first tries to append the local/search-domain to requests. That is an important change from previous versions where search-domains are appended only when the client application only specifies the host-part.

In the last couple weeks I've come across number of different broadband CPE's (multiple brands) which have a DNS-forwarder that fails to forward nxdomain responses to the clients. In the past these clients would only experience delays for non-existent hosts. After upgrading to karmic they get a 20sec delay for every request. I.e. the user types "ubuntu.com" in the browser, karmic first tries "ubuntu.com.searchdomain" and sits waiting as the nxdomain-response is lost.

I may have gotten protocol orders wrong in my analysis, or the dns-lookup-mechanism has been altered in the last libc update. The net result however, is still that every attempt by an application to connect to a v4-only host is preceded by a dns-request that result in a lost nxdomain response. Example: capturing DNS packets while connecting to a webserver with no v6-support reveal the following order of DNS queries and responses:

1. The client searches for an AAAA record. The DNS-server returns SOA with noerror.

2. The client tries the local variant of the AAAA record. The DNS-server returns NXDOMAIN which is lost in the faulty DNS-forwarder.

3. After timeout (20sec) the client goes looking for an A-record and succeeds.

Wouldn't it be preferable to prioritise differently? The client could send concurrent requests for A and AAAA, and drop the attempt on the local variant of AAAA when it gets one or more valid a-records.

glibc 2.10 does AAAA+A queries in parallel. I don't know if it does that also for the ones in the search path, which seems to be the problem you are describing above.

Nevertheless, search path should (afaik) only be applied to non-FQDN hostnames (eg 'www' or 'hostname') not to anything containing already a domain (eg 'www.domain'). When this is done and users type eg 'ubuntu.org' then the local search path does not come into play.

The problem that I have seen with recursors (even one on an old dd-wrt as even dnsmasq had this issue quite some time ago, but if you don't update it doesn't get fixed ;) was that it simply completely silently dropped AAAA queries. It didn't even try to forward them. No response nothing. Even for www.ubuntu.org etc. Which is another error case from the scenario you describe, which is even funnier, as NXDOMAIN should definitely be handled properly (if they don't how the heck does that DNS recursor even work when somebody mistypes a URL ? :).

This is an Ubuntu bug, plain and simple. My DNS resolver didn't suddenly grow issues because I updated my OS. This is completely unacceptable for an operating system that touts itself as being "Linux for Humanbeings", where is the user-friendliness in breaking Internet connectivity for a lot of people? By all means, change it but give a fair warning; "If you are not using a very modern router do not upgrade as we don't care about you" and provide a one-click button after install and fixes the issue, rather than having people chasing their tails, disabling IPv6 etc. etc. Especially since most of those "fixes" are voodoo magic posted by clueless idiots -- fixing Firefox and no other application is not a fix.

1) This will effectively install pdns_recursor which is a DNS recursor that simply works(tm) and it installs the resolvconf framework (which you most likely already have)
2) this echo sets the nameserver to 127.0.0.1, aka pdns
3) update resolv.conf with the above info

You should now have "nameserver 127.0.0.1" in /etc/resolv.conf and all your DNS queries should be super duper fast again (also because they get locally cached a bit ;)

Of course if you have a firewall between your host and the Internet where DNS servers exist the above might not work when DNS gets blocked...

I would almost suggest that Ubuntu make the above the default. The problem is though that little firewall thing, if that is there or you visit some netcafe or other network where only HTTP/HTTPS works, then indeed it does not work...

Cromartie [2009-11-09 13:31 -0000]:
> This is an Ubuntu bug, plain and simple.

Folks, please calm down. As the bug status shows, it is an
acknowledged and open bug report, and there was no official statement
like "your router sucks, bad luck, go away". There is a new glibc
package for testing, and several workarounds were proposed, and
eventually we'll fix this in karmic-updates properly.

> Especially since most of those "fixes" are voodoo magic posted by
> clueless idiots -- fixing Firefox and no other application is not a fix.

Watch your language. The other people subscribed here are trying to
help! This conduct is unacceptable.

> Cromartie [2009-11-09 13:31 -0000]:
> > This is an Ubuntu bug, plain and simple.
>
> Folks, please calm down. As the bug status shows, it is an
> acknowledged and open bug report, and there was no official statement
> like "your router sucks, bad luck, go away". There is a new glibc
> package for testing, and several workarounds were proposed, and
> eventually we'll fix this in karmic-updates properly.
>
> > Especially since most of those "fixes" are voodoo magic posted by
> > clueless idiots -- fixing Firefox and no other application is not a fix.
>
> Watch your language. The other people subscribed here are trying to
> help! This conduct is unacceptable.
>
> Martin
> --
> Martin Pitt | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “glibc” source package in Lucid: Confirmed
> Status in “network-manager” source package in Lucid: Invalid
> Status in “glibc” source package in Karmic: Confirmed
> Status in “network-manager” source package in Karmic: Invalid
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>

I've seen this behavior in quite few installation I have done; and saying "install a DNS server/Edit sysctl.conf" should not be the answer to fix the problem, not everybody have the skills required to do that, and it should not be a requirement at all. I don't think this could be fixed for karmic at this point but it should be fixed for lucid, otherwise the "common" users (not experts) will get tired of using "software" that doesn't work (They can't browse the web the way they like). So far I just disable IPv6 in firefox after installing ( network.dns.disableIPv6 ), thats quite enough to make most users happy.

I think that given the fact that Ubuntu is free, its pretty good for an
operating system, even though sometimes it does come with hick ups. But I am
sure thats something, Ubuntu developers will strive to get ironed out in the
future. But like I said, its pretty good for being free.

> I've seen this behavior in quite few installation I have done; and
> saying "install a DNS server/Edit sysctl.conf" should not be the answer
> to fix the problem, not everybody have the skills required to do that,
> and it should not be a requirement at all. I don't think this could be
> fixed for karmic at this point but it should be fixed for lucid,
> otherwise the "common" users (not experts) will get tired of using
> "software" that doesn't work (They can't browse the web the way they
> like). So far I just disable IPv6 in firefox after installing (
> network.dns.disableIPv6 ), thats quite enough to make most users happy.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “glibc” source package in Lucid: Confirmed
> Status in “network-manager” source package in Lucid: Invalid
> Status in “glibc” source package in Karmic: Confirmed
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>

I am experiencing the same problem. I am using one of Germany's largest Internet provider (T-Online) with a recent DSL/router combo that is handed out by them to their customers (Speedport W 303V, got is 6 months ago, updated to the newest firmware). So I think that probably a larger number of people than you think are affected by this bug (at least in Germany). I was able to bring my system into a usable state with the workaround of disabling IPv6 in the kernel by editing grub config file. But non-technical people, who cannot do things like that, will have a very bad experience and probably stop using Ubuntu, because the network is unusably slow for them. Please take this bug serious. I would say it is critical.

I have the same problem with my WRT54G router. I know this is a bug in the firmware not in Linux, but I do see this as a regression simply because I did not have the problem before. I simply don't need IPV6 yet, when I do, I'll think about upgrading my routers.

I now worked around it by installing the pdns-precursor, and setting 127.0.0.1 as DNS, but It would be very nice if a user-friendly workaround was added. Also, I can't use the internal DHCP-to-DNS functionality of my router anymore.

The same issue for me on DSL. I was working on 9.04 for a few months without problem, now absolutely no internet connection on 9.10 - neither in Mozilla, nor in Synaptic. However, as I run dual boot with XP, on Windows, network connection is fine. Lucky me...

There are so many bugs launched and so many forums with dozens of workarounds for experts, creating new bugs... Can somebody write a step by step solution for newbie?

0. The network is not working. (Don't tell me to download something).
1. What to do/rewrite/edit/launch to make a temporary workaround - network somehow working (mozilla, synaptic, or whatever)
2. What to do to download/get somehow some official fix (not creating new bugs) ... if it already exists.

I'm not satisfied with answers like "upgrade NM with ppa" or "try pppoeconf"... it doesn't tell me much.

Please, someone, make a clear summary.

Do not send me another links to read endless forums... I have spent hours reading them... I'm used to the plurality of responses and solutions while working with Ubuntu, but having such a major problem, I'm loosing my patience. It is a major issue and newbies are not able to spend days reading forums, that offer so many workarounds, that need to be topped by other workarounds... I need to see what to do right now and not to read what hundreds of people tried... Where is Ubuntu's official solution?

1) This will effectively install pdns_recursor which is a DNS recursor that
simply works(tm) and it installs the resolvconf framework (which you most
likely already have)
2) this echo sets the nameserver to 127.0.0.1, aka pdns
3) update resolv.conf with the above info

You should now have "nameserver 127.0.0.1" in /etc/resolv.conf and all
your DNS queries should be super duper fast again (also because they get
locally cached a bit ;)

Of course if you have a firewall between your host and the Internet
where DNS servers exist the above might not work when DNS gets
blocked...

I would almost suggest that Ubuntu make the above the default. The
problem is though that little firewall thing, if that is there or you
visit some netcafe or other network where only HTTP/HTTPS works, then
indeed it does not work...

> The same issue for me on DSL. I was working on 9.04 for a few months
> without problem, now absolutely no internet connection on 9.10 - neither
> in Mozilla, nor in Synaptic. However, as I run dual boot with XP, on
> Windows, network connection is fine. Lucky me...
>
> There are so many bugs launched and so many forums with dozens of
> workarounds for experts, creating new bugs... Can somebody write a step
> by step solution for newbie?
>
> 0. The network is not working. (Don't tell me to download something).
> 1. What to do/rewrite/edit/launch to make a temporary workaround - network
> somehow working (mozilla, synaptic, or whatever)
> 2. What to do to download/get somehow some official fix (not creating new
> bugs) ... if it already exists.
>
> I'm not satisfied with answers like "upgrade NM with ppa" or "try
> pppoeconf"... it doesn't tell me much.
>
> Please, someone, make a clear summary.
>
> Do not send me another links to read endless forums... I have spent
> hours reading them... I'm used to the plurality of responses and
> solutions while working with Ubuntu, but having such a major problem,
> I'm loosing my patience. It is a major issue and newbies are not able to
> spend days reading forums, that offer so many workarounds, that need to
> be topped by other workarounds... I need to see what to do right now and
> not to read what hundreds of people tried... Where is Ubuntu's official
> solution?
>
> Thank you
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “glibc” source package in Lucid: Confirmed
> Status in “network-manager” source package in Lucid: Invalid
> Status in “glibc” source package in Karmic: Confirmed
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confi...

That is not a fix, it is a "Workaround", and maybe it will work at the house, but in a secure network (like a company network) it will not work and it will make Ubuntu useless.

The only real fix to this is disabling IPv6 support (for desktop version). In the real world pretty much no one uses IPv6, I'm not quite sure why Ubuntu would want this enabled by default, maybe they can do it when everybody start using IPv6, meanwhile, it is worthless.

> version). In the real world pretty much no one uses IPv6, I'm not quite
> sure why Ubuntu would want this enabled by default, maybe they can do it
> when everybody start using IPv6, meanwhile, it is worthless.

Actually, based on my studies, over 4 million people use IPv6
transport on the IPv6 Internet. Many are unaware of the fact. Based on
a study of the DNS root servers, there are 10-20 million systems
making AAAA request, without IPv6 transport. Lastly, there are about
250-400 million systems shipped in the last 4 years with IPv6 services
enabled.

On the security side, if your firewalls and routers (and other IA
gear) are unable to process IPv6 packets, they are also unable to
protect against native and tunneled IPv6 attacks. So again the issue
is not that Ubuntu needs IPv6 disabled, the issue is people need to
update their infrastructure to IPv6 enabled devices to properly
protect their networks.

On Wed, Nov 18, 2009 at 3:19 PM, Ricardo Fernández <email address hidden> wrote:
> #159
>
> That is not a fix, it is a "Workaround", and maybe it will work at the
> house, but in a secure network (like a company network) it will not work
> and it will make Ubuntu useless.
>
> The only real fix to this is disabling IPv6 support (for desktop
> version). In the real world pretty much no one uses IPv6, I'm not quite
> sure why Ubuntu would want this enabled by default, maybe they can do it
> when everybody start using IPv6, meanwhile, it is worthless.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a member of IPv6 Task
> Force, which is a direct subscriber.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “glibc” source package in Lucid: Confirmed
> Status in “network-manager” source package in Lucid: Invalid
> Status in “glibc” source package in Karmic: Confirmed
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no (non-loopback) IPv6 interfaces configured. Routers which do not repond to this cause the lookup to take 20 seconds (until the IPv6 query times out).
>

Also they are over 600+ million internet users around the world (maybe more?), 4 millions using IPv6 is around 0.7% of the internet users.. so yeah, pretty much no one. And how many of thoses 4 millions use Ubuntu ? let me guess it should be below 0.1%, so, making IPv6 enabled by default will only be used by 0.1% (below that number to be honest). Default should be for the other 99.9%.

Yes they are a lot of systems shipped with IPv6, the point is thoses systems _works_ and Ubuntu 9.10 doesn't (not the whole distro of course, just this "cant use internet thing").

You can't ask everybody to update their whole network hardware to IPv6 to make Ubuntu works, thats quite hard to do, it is easier just to switch distro (Like Fedora, Debian, anything) or just Windows 7, and thats what most people will do when they try to use their favorite distro (Ubuntu) and notice the slow internet.

On the security side, just because a firewall/router doesn't process IPv6 it doesn't mean you can use some sort of attack, you can't attack something that doesn't understand you, at most you can just try to DoS it, so I'm quite sure no one is afraid of a IPv6 attack over a IPv4 network.

From libc.NEWS file:
Starting with version 2.9-8, unified IPv4/IPv6 lookup have been enabled
in the glibc's resolver. This is faster, fixes numerous of bugs, but is
problematic on some broken DNS servers and/or wrongly configured
firewalls.

If such a DNS server is detected, the resolver switches (permanently
for that process) to a mode where the second request is sent only when
the first answer has been received. This means the first request will
be timeout, but subsequent requests should be fast again. This
behaviour can be enabled permanently by adding 'options single-request'
to /etc/resolv.conf.

Actually, if you are having the problem with your ISP, I suspect a
large number of technical and non-technical people on the same ISP are
having timeout problems with other operating systems and applications.
The difference is that you are a knowledgeable user that has
identified and knows how to solve the problem. E-mail me directly with
the ISP name and I would be willing to contact them about the problem.

Actually my studies show that 75% of device on the internet today have
or could have IPv6 enabled. I was only sharing the 'conservative
numbers'. The biggest jump in IPv6 users in the last 12 months was due
to BitTorrent clients on windows system enabling IPv6 tunneling
(Teredo).

Over the next 4 years, all of the major ISP's are expected to move
quickly to dual stack and IPv4 over IPv6 transport. Comcast should be
the first, followed the the crowd of cable provides then telcom
providers. So 0.1% might be small today, but should get to +1% by the
end of 2010.

Again on the security side, there are many attacks which have been and
are accruing on unsuspecting networks which have IPv6 enable but do
not have proper IPv6 security controls (IPv6 capable firewalls,
routers, IDS,...). The first attack was back in 2002 on a debian
distro that did not have IPv6 firewall enabled, but did have the IPv4
enabled. So continue to believe there are no IPv6 security attacks,
the same way as many people said back in 2002, there are no wifi
attacks and WEP is secure!

BTW, I am not having the problem, I loaded Miredo on my Ubuntu system
and it seem to be fine. With that in mind, have we considered just
having Miredo installed by default on the Distro?

Joe

On Wed, Nov 18, 2009 at 5:39 PM, Ricardo Fernández <email address hidden> wrote:
> #162
>
> Yeah I'll tell my ISP to upgrade their Hardware because my Ubuntu
> doesn't work. That will surely work. *sigh*
>
> Also they are over 600+ million internet users around the world (maybe
> more?), 4 millions using IPv6 is around 0.7% of the internet users.. so
> yeah, pretty much no one. And how many of thoses 4 millions use Ubuntu ?
> let me guess it should be below 0.1%, so, making IPv6 enabled by default
> will only be used by 0.1% (below that number to be honest). Default
> should be for the other 99.9%.
>
> Yes they are a lot of systems shipped with IPv6, the point is thoses
> systems _works_ and Ubuntu 9.10 doesn't (not the whole distro of course,
> just this "cant use internet thing").
>
> You can't ask everybody to update their whole network hardware to IPv6
> to make Ubuntu works, thats quite hard to do, it is easier just to
> switch distro (Like Fedora, Debian, anything) or just Windows 7, and
> thats what most people will do when they try to use their favorite
> distro (Ubuntu) and notice the slow internet.
>
> On the security side, just because a firewall/router doesn't process
> IPv6 it doesn't mean you can use some sort of attack, you can't attack
> something that doesn't understand you, at most you can just try to DoS
> it, so I'm quite sure no one is afraid of a IPv6 attack over a IPv4
> network.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second delays by de...

8.04, 8.10, 9.04 (Ubuntu), Windows XP, Windows Vista, Windows 7, Fedora 9/10/11, Debian Lenny (and sid), all thoses Distro/OS works like a charm in my network, Ubuntu 9.10 (desktop-clients in my network) have a real slow "internet", so calling an ISP because a Linux distro doesn't work is not a real solution.

Please understand this is an Ubuntu 9.10 problem it is not an ISP or router or hardware or anything else but Ubuntu, simple as that. This isn't a forum about how cool IPv6 is and why we should use it, this is a bug tracking system where people report "Hey my internet doesn't work", so asking those people to upgrade their external hardware/software isn't a solution or a fix.

The previous version of ubuntu (windows and maybe OSX caches dns request or work differently) workaround this router bug. I seems that the workaround was causing other issues (see the 2 bugs mentioned earlier).

I tried "options single-request' in /etc/resolv.conf" yesterday and so far it doesn't work for me, but i need 2-3 days to get feedback from my ubuntu users in the network to see how it goes. The problem with this, is that the resolv.conf will change every time i change dhcp server, so I need to make the option permanent, I can't ask my users to edit system files to fix this, they have no idea how to use vi or sudo (to make the option permanent, it is not only editing /etc/resolv.conf).

I haven't tried the nscd one, I only use it to cache the ldap info, and I'm not quite sure I would like to have a local cache of my dns in each pc but thats me.

What is the status of this bug? Above it looks like it was fixed; "status: Confirmed → Fix Released", but at the top it only says the status is "Confirmed". If it is fixed, is the fixed package available now via Update Manager? Or do I have to enable other repos (Testing, Proposed, et al.) to get the fixed package?

I've used so many different work-arounds that I'm sure what worked and what didn't. Overall I'd like to fix this properly so does anyone know of a router or a list of routers that don't suffer from this problem? I am using a DSL-G604T on wireless.

Carlin [2009-11-20 7:01 -0000]:
> What is the status of this bug? Above it looks like it was fixed;
> "status: Confirmed → Fix Released", but at the top it only says the
> status is "Confirmed".

It was wrongly closed and reopened.

> If it is fixed, is the fixed package available now via Update
> Manager? Or do I have to enable other repos (Testing, Proposed, et
> al.) to get the fixed package?

As I wrote earlier, there is a package from a PPA which reapplies a
patch to glibc to fix this. But it reopens two other bugs. Laurent's
suggestion seems better, but I can't test it here (I'm in Dallas at
UDS). I can test it next week when I'm back home, or someone else test
Laurent's suggestion first.

"options single-request" in /etc/resolv.conf works, but it has two drawbacks:

1) The first time you want to access a website, it will be slow.

2) when the process terminates, i.e. when you close the application or when it ends by itself (web browser, apt-get, etc.), you lose all your "fast DNS resolving" stuff. When you reopen the browser, it will be slow again. Take apt-get: you run it for updating or installing some packages, and it will close itself at the end of the operation, and all is lost. Next time you run apt-get, it has to resolve everything again with the slow method...

this bug also cripples my system as well. i don't know why none of the workarounds gave me a consistent solution. They fix the system for a while, but then for some reason I go back to square one(I guess I install something, or something changes configuration files). This is the biggest problem I had with ubuntu in 2 and a half years I have been using. Disabling ipv6 must not be the solution.
The only thing that works well now for me is torrents. Updating repositories is a pain now

Here is one more thing:
Because of this bug I have gone back to jaunty. There, when I added a repository for firefox, it upgraded my xulrunner and installed sth called xulrunner-gnome-support. Then I began to have the same problem. After downgrading xulrunner to whatever in the official repos my internet became OK.
Ping times went back from 2500 ms to 60ms again

I am using the workaround - adding "ipv6.disable=1" to the GRUB_CMDLINE_ LINUX_DEFAULT line in /etc/default/grub- and this works well for me. After the recent updates to the LIBIND packages , i tried removing this entry, and the problem still exists, so those were no help. Still waiting for a resolution.

Could someone write a template letter (I would translate to french).
because to be effective such a letter should presumably refer to some
norms, standards or conventions, which most of us are not aware of.

Mark Schouten skribis (esperanto estas la unua internacia lingvo):
> On Fri, 2009-12-11 at 11:30 +0000, Jonzer wrote:
>> It is nothing short of incredible that this issue still exists.
>>
>> Very very sad.
>>
>
> I agree with everyone that this issue should be fixed in Ubuntu,
> somehow. But has anyone even bothered to complain at their ISP or modem
> provider, who are the actual cause of this issue?
>
> DNS Resolution isn't some small part of a operating system, you cannot
> 'just fix this here a bit' and see what happens.
>
> So, give the developers some time to fix this issue and do it right, and
> don't forget to complain at your own suppliers.
>

On Sat, 2009-12-12 at 09:51 +0000, robert leleu wrote:
> Could someone write a template letter (I would translate to french).
> because to be effective such a letter should presumably refer to some
> norms, standards or conventions, which most of us are not aware of.

I think a complaint from a 'normal' user (not a nerd or professional
ipv6 evangalist) might work better. The nerd always wine, the response
is always 'we never get requests from normal users'.

That might do it on the (very) long term, and if this is what the problem is, it has to be done anyway.

But I don't see how that would solve the problem at hand *NOW*.
I'm experiencing the problem and I'm connected behind a recent Linksys BEFVP41 VPN router, downstream my DSL box, that I use to isolate / protect me from the network. Linksys is Cisco, btw, the king of the routing world. And the box is new, bought in 2009. Latest firmware, april 2009.http://www.linksysbycisco.com/US/en/support/BEFVP41/download
And I do have the problem.
There are myriads of people and small and large businesses in the same situation.
Expecting that all those are going to rush buying a new router (and for many, finding someone to config it for them) because Linux misbehaves (even if it "rightly" misbehaves) seems a wild goose chase to me.
Many would rather conclude that Windows is still the king of the hill after all and change the piece of software that reveals the problem for the one that doesn't.

> Exactly, I couldn't agree more, this should be moved to critical. We're
> having serious problems at the office and are thinking to change to
> OpenSUSE or other linux distro.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “glibc” package in Ubuntu: Confirmed
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “glibc” source package in Lucid: Confirmed
> Status in “network-manager” source package in Lucid: Invalid
> Status in “glibc” source package in Karmic: Confirmed
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>
> *** PLEASE DO NOT COMMENT ON THIS BUG unless you have something
> constructive to say. Everything that can be said has already been said, and
> if you comment, you are just adding noise. Please let those that actually
> know what they are doing concentrate on fixing this bug from now on. ***
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/417757/+subscribe
>

Here is (hopefully) a "constructive" suggestion. Since IPv6 is going to be the future of the internet it makes sense to try and support it. Obviously thought there is going to be a transition period where support for it is not going to be always available (as is the case at the moment where most home routers do not support it). So would it not make sense for Ubuntu to check for IPv6 connectivity/services either at boot time or as network interfaces go up and down or periodically? If there is IPv6 connectivity/services it should use it otherwise revert to IPv4. That way this problem might be more future proof.

Accepted eglibc into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I noticed using torrent software like qbittorrent (1.5.6) on Karmic (but not on Jaunty) would kill all network functionality for _other_ software for some minutes, and when up afterwards resolving connections the network would be very sluggish. No such problem with Transmission (better default settings?). This coupled with the ipv6 dns problems...

I tried the Karmic patch, then an upgrade to Lucid. DNS is fast when it works, but I often lose all DNS functionality for all applications for several minutes randomly. At startup a simple wget in shell will work fine, yet opening chrome/firefox (with multiple tabs) will block dns calls for a long time.

This fix is towards the right direction, but not complete to mitigate all DNS-issues by any means based on my usage (ZyXEL router).

cheerios_ [2010-01-04 20:06 -0000]:
> This fix is towards the right direction, but not complete to mitigate
> all DNS-issues by any means based on my usage (ZyXEL router).

It's the very same patch that we have carried since dapper or even
earlier. Did you have such problems before? Perhaps you still have
another workaround in place which now interferes with the new patch?

I tested the karmic-proposed package on my work machine, however, I'm still having intermittent issues with this. Since this is a work machine, I'm at the mercy of our IT department as far as routers and DNS resolution goes. I've disabled all workarounds, installed the new package and rebooted. It worked for about five minutes before going back to the same behavior I was seeing previously.

All throughout this bug report, a lot of people (developers, I'm assuming) have commented that the routers are broken and it shouldn't be on Ubuntu to fix the problem. I'm sorry, but if I go from a working version of Ubuntu (Jaunty) and upgrade, I expect everything to work equally as well, if not better, than the previous release.

On Tue, 2010-01-05 at 12:51 +0000, Brad Peters wrote:
> I tested the karmic-proposed package on my work machine, however, I'm
> still having intermittent issues with this. Since this is a work
> machine, I'm at the mercy of our IT department as far as routers and DNS
> resolution goes. I've disabled all workarounds, installed the new
> package and rebooted. It worked for about five minutes before going
> back to the same behavior I was seeing previously.

Wouldn't tcpdumps come in handy in these cases so we see what actually
happens on the network stack?

FWIW:
1. I'm having this problem intermittently
2. When it occurs on my Karmic box, it also occurs on a Windows 7 laptop
(wireless) on my home network.
3. Other computers on the network (XP both wired and wireless) remain
functional DNS wise, except that sometimes my web request to the router
config page is forwarded to the Karmic box (see 4b below). Router reboot
required to fix.
4. Upgrading my router (D-Link DIR-655) firmware seemed to help, but
after three days of flawless function, the problem occurred again. I
found that I had not checked the (new with latest firmware) 'Advanced
DNS' checkbox in the router config. I checked that and rebooted the
router. All is well since then, <24 hours.
4a. Because of domestic issues, I shut down all computers and the home
network at night and reboot each morning.
4b. Port 80 is forwarded from the router to apache on my Karmic box.
5. My upgrade from Jaunty to Karmic (Kubuntu) is seriously broken. Only
terminal shutdowns work (Bug#418509) K3b ruins disks but doesn't burn
them and no media players function properly except vlc and totem.
6. A work machine with similar configuration upgraded to Karmic without
incident.

Brad Peters wrote:
> I tested the karmic-proposed package on my work machine, however, I'm
> still having intermittent issues with this. Since this is a work
> machine, I'm at the mercy of our IT department as far as routers and DNS
> resolution goes. I've disabled all workarounds, installed the new
> package and rebooted. It worked for about five minutes before going
> back to the same behavior I was seeing previously.
>
> All throughout this bug report, a lot of people (developers, I'm
> assuming) have commented that the routers are broken and it shouldn't be
> on Ubuntu to fix the problem. I'm sorry, but if I go from a working
> version of Ubuntu (Jaunty) and upgrade, I expect everything to work
> equally as well, if not better, than the previous release.
>

[ Martin Pitt ]
* debian/patches/series: Apply any/local-ipv6-lookup.diff again to fix
painfully long timeouts on DNS resolution, if routers do not send an
answer to AAAA (IPv6) DNS queries. With this patch those DNS requests are
not sent in the first place if there are no routable IPV6 interfaces.
(LP: #417757) This reopens LP #239701, #374674, so a full solution would
need to fix the patch properly.

I concluded too fast.....I just experimented slow connection to smtp, so I put back the "IP" smtp, which worked fine......
I stay with ipv6 activated, and will report if I experiment delays in browsing....

I' ve been experiencing intermittent slow browsing in Firefox 3.5 with IPv6 enabled. It's much better than it was but there are periodic 3 to 4 second delays in loading web pages. Additionally, preset radio stations in Rhythmbox sometimes take 3 to 7 seconds to load. Update manager is slower to start as well. When I switch over to Jaunty (with Firefox 3.5 installed) on the same machine, I see none of these issues.

My Internet connection via cable and router is still as slow as before. Downloads are about 100kps were the very same machine (Fujitsu Siemens Amilo A notebook) running Windows XP does about 600kps.
Which information can I provide to help you help me?

RobertL [2010-01-12 21:20 -0000]:
> My Internet connection via cable and router is still as slow as
> before. Downloads are about 100kps were the very same machine
> (Fujitsu Siemens Amilo A notebook) running Windows XP does about
> 600kps.

This is totally unrelated. The symptom of this bug is that it takes
some 10 seconds to establish a connection (due to slow name
resolving). It does not affect download/upload speed at all.

I suspected user (as in me) error after my report yesterday. I ran all updates on my laptop running Ubuntu Netbook Remix 9.10 (Karmic) and tested browsing with ipv6 enabled, playing the radio in Rhythmbox and checking for updates. Speeds seemed normal and similar to what I was seeing using 9.04. I apologize for yesterday's erroneous results.

To clarify my terminology per Martin Pitt, I should have said that there are no longer any delays when browsing, using Rhythmbox and checking for updates. The bug appears fixed on my netbook running UNR 9.10/Karmic. I will test again on my desktop machine running Karmic.

This problem is not fixed on my computer, unfortunately. I'm a first time poster here - been watching this bug for a long time. It appeared to be fixed for a day or two, but I still have the long delays on page requests. Also, I've tried downloading large files via firefox and I've also been experiencing delays in the start of the downloads, as well as long interruptions. Watching this on the system monitor confirms, when this bug acts up, there is zero incoming transmissions via wireless. The only work around I've been able to get to work is to open a new window in firefox, and hit stop + refresh until it 'unlocks' itself and the incoming transmissions restart.

Also, I don't seem to have the "eglibc" package installed on my version of Karmic (Desktop, 64 bit). Is this embedded in another package? I've found "eglibc-source" in the repos - am I supposed to install this?

Sorry for the questions, but this has been a most frustrating bug and I'd like to see some resolution. Thanks for all your hard work folks!

On Mon, 2010-01-18 at 23:31 +0000, Michael McLeish wrote:
> This problem is not fixed on my computer, unfortunately. I'm a first
> time poster here - been watching this bug for a long time. It appeared
> to be fixed for a day or two, but I still have the long delays on page
> requests.

Perhaps delayed AAAA requests are not your only problem. If you're
adventurous, you could have a look at what seems to be holding it up in
Wireshark. (Though that's for another bug report.)

> Also, I don't seem to have the "eglibc" package installed on my version
> of Karmic (Desktop, 64 bit). Is this embedded in another package?

eglibc is just a source package name: the binary packages that result
from it that appear in your package manager are not necessarily (but
usually are, but in this case, are not) named the same.

Generally speaking this bug is not solved.
I just had a general crash, and installed a new Ubuntu Karmic.....Whaouh! If I were a newbie I'd erased the whole stuff....

I, very slowly, googled to patches, choose the "Grub" patch......and it works for Firefox, Thunderbird and apt-get.....

But the Ubuntu version now distributed has to be considered as bugged......and since installation are usually made from downloaded CD, and requires connection to internet, why not write the "good" line in Grub config, and at the first connection check the internet provider against a list of providers, and deliver a "good new" message such as:

"Hello, you're happy to have such an internet provider....he uses uptodate technology, and we can set your Ubuntu to use it. Paay attention if you change your provider, or connect from other sites: you may experience slow connection. Please consult such a page for further explanations", and automatically modify the Grub configuration to use ipv6

I couldn't get wireless to work properly on my box after Jaunty->Karmic upgrade. Fresh Karmic install works better. I still get long "Resolving host..." timeouts (even against google.com) now and then, but mostly things work. Not sure what went wrong during the upgrade to cause all the problems.

Regardless of whether I use a local caching nameserver, pdns-recursor, or a name server on a CentOS 5 box, the timeout phenomenon is the same. From a gut feel point of view, I'd say it's worse when using the local caching nameserver.

Running WinXP in VMWare Workstation 7 on the same physical machine with no timeouts. (i.e. While it's timing out in firefox I switch into XP and pull the same page. Comes up instantly.)

My feeling is we're dealing with some kind of race condition in the resolver library because it happens when doing a number of simultaneous DNS requests.

Open 20 or so tabs in firefox to various websites with varying load times. Close firefox. Reopen firefox and at the same time open Thunderbird. In this scenario Thunderbird will timeout 100% of the time as will the majority of tabs in firefox.

It's intermittent. In FF, I can have one tab that's loading and other that's timing out. Sometimes it will pull the main html page but timeout on graphics or CSS.

I would like to be able to run Kubuntu instead of having to fallback to CentOS 5. I am willing to lend a hand to track this down if you would like to give me some tests to run. I can reproduce this problem consistently.

> It's fixed in Karmic. But still present on Lucid. Please fix it before
> Lucid release, not like for Karmic (fix was too late).
>
> @manu: it has nothing to do with wireless. It's the same problem with
> wired connection.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eglibc” package in Ubuntu: Triaged
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “eglibc” source package in Lucid: Triaged
> Status in “network-manager” source package in Lucid: Invalid
> Status in “eglibc” source package in Karmic: Fix Released
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>
> *** PLEASE DO NOT COMMENT ON THIS BUG unless you have something
> constructive to say. Everything that can be said has already been said, and
> if you comment, you are just adding noise. Please let those that actually
> know what they are doing concentrate on fixing this bug from now on. ***
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/+subscribe
>

> I thought it was in karmic-updates, or maybe karmic-proposed repository.
> Which version of libc6 package do you have? I have 2.10.1-0ubuntu16 from
> karmic-updates.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eglibc” package in Ubuntu: Triaged
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “eglibc” source package in Lucid: Triaged
> Status in “network-manager” source package in Lucid: Invalid
> Status in “eglibc” source package in Karmic: Fix Released
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>
> *** PLEASE DO NOT COMMENT ON THIS BUG unless you have something
> constructive to say. Everything that can be said has already been said, and
> if you comment, you are just adding noise. Please let those that actually
> know what they are doing concentrate on fixing this bug from now on. ***
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/+subscribe
>

I don't want to use the update manager since I haven't installed
any updates after the fresh installation of Karmic(I use Karmic on an USB drive)
and updating ruins my system(it just won't boot after updating. I asked
a question about this update problem elsewhere in Launchpad :https://answers.launchpad.net/ubuntu/+source/yelp/+question/99635 )

Maybe I can use Synaptic or use a command from terminal
or download something directly from the net and install it?

1. Do you have the package source "karmic-updates" enabled? If no, enable it in Synaptic just for one time. After enabling it, do an update (but not an upgrade!).
2. Look for the libc6 package and choose the version (Ctrl + E, or in the "Package" Menu). Choose the newest which should be 2.10.1-0ubuntu16 from karmic-updates and click the green checkmark ;) Should work.

Thank you Tourion. I Installed the new eglibc package ( libc6 2.10.1-0ubuntu16).

I don't think it has fully resolved the problem.(but sure my browsing gets less delays now)
I still have the delay problem with some websites(even the with the google.com !).
Well, I certainly do not want to "add more noise" to this discussion.

Thank you all again.

P.S. I really hope that the Lucid Lynx will be released with no such bug.

From what I am observing here, the IPV6 problem is not the sole cause of slow lookups and connection speed. Despite turning off IPV6, running my own name server (even a local caching one), modifying /etc/nsswitch.conf, tweaking settings in ethtool, etc. etc. etc. I still get stalls and failed connections so often that the distribution is on the verge of unusable.

To reproduce this problem open 15 tabs or so in firefox. close firefox. Open it again and open another network app like Thunder bird at the same time. More often than not many tabs will fail to load and you'll get a failed to connect error from Thunderbird.

As has been reported, this does not happen, for instance, in WinXP running in VMware on the same physical machine.

I am behind a D-Link DI-707 switch.

Unfortunately, it looks like I am going to have to bail on Ubuntu. It's too bad. The distribution has a lot of promise.

@Laurent yes. /ALL/ network access regardless of application is affected. Please re-read the report I wrote. Yes, this has nothing to do with the IPv6 DNS lookup problem. IPV6 AAAA record lookup was one issue that would cause the slow connections so many people are experiencing. My point is that while the IPv6 lookup issue has been resolved, it is not the only cause of the slow dns lookup/connection symptoms people are experiencing.

As I have said, IPV6 is /disabled/ on my machine via grub. IPV6 is disabled in firefox. IPV6 IS NOT THE SOLE REASON FOR SLOW DNS AND NETWORK CONNECTION IN UBUNTU. i have verified this here. Maybe it should be listed as a separate bug, but none of the other bugs I have found (of which there are many) seem to match the symptoms I'm seeing here exactly.

Slow dns lookups. DNS lookup failure 30% of the time or so. Connection failure 30% of the time or so. Extremely slow net connectivity over a wired connections. I've tried every combination of work around I could find on the net to no avail.

Then I upgraded the firmware on my DI-707 router and suddenly the problem disappears. The confusing thing is that Ubuntu 8.04, WinXp and EVERY SINGLE DISTRIBUTION BEFORE had no issue with this router. It seems to be restricted to recent 2.6 kernels.

I had read somewhere, I'm sorry I have forgotten where, that there was some TCP/IP standards issue that someone had decided to implement too strictly in recent kernels which caused connections through many legacy routers/switches/firewalls to fail (which is why I tried the firmware upgrade).

At this point, for me, the problem seems to be solved, but I have the feeling that there are many Ubuntu users out there that are still suffering from slow/failing dns lookups and the IPV6 issue does not explain all of them.

There is still some network level problem.

But like I said, the firmware upgrade on my DI-707 seems to have worked around whatever problem Ubuntu has.

I'm reporting this in an attempt to be helpful; too often in my own software business customers who are running into trouble with our software simply don't report their experiences so we have no idea that there's a problem.

@Laurent Yes, I was thinking the same thing since it's now fixed for me.

However, if you do some searches, even in the Ubuntu forums I think, you'll find dozens if not hundreds of posts from people saying they turned off IPV6 but still had slow lookups/connectivity. There was one thread somewhere where it was mentioned that this was due to Ubuntu/Linux now implementing some standard (I don't know which one) more rigidly than many router/switch manufacturers. That was the reason I thought to upgrade the firmware in the DI-707.

I have a wired connection. And I recently changed my modem to a much newer
one. I've been having issues recently, which seemed to spawn from an updated
vbox. I have ubuntu running as quest on windows 7. After the update of vbox,
my connection would be very strange, at start up of Firefox, everything
would load. After couple seconds or so, the connection would grind to a
halt. Recently, I activate IPV6 on Firefox, and the problem has gotten much
much better, but not completely alleviated. Some pages are constantly trying
to load, but never get there. But thats much better than before. Before I
switched the flag in Firefox, pretty much all the pages would be stuck in
load mode, it was so frustrating.

Windows 7 seems to work fine
Ubuntu seems like there are some issues still.

On Mon, Feb 22, 2010 at 5:19 PM, Yermo <email address hidden> wrote:

> @Laurent No. Wired connection exclusively.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “eglibc” package in Ubuntu: Triaged
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “eglibc” source package in Lucid: Triaged
> Status in “network-manager” source package in Lucid: Invalid
> Status in “eglibc” source package in Karmic: Fix Released
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>
> *** PLEASE DO NOT COMMENT ON THIS BUG unless you have something
> constructive to say. Everything that can be said has already been said, and
> if you comment, you are just adding noise. Please let those that actually
> know what they are doing concentrate on fixing this bug from now on. ***
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/+subscribe
>

I kept having issues even after the fix was released until poking into NetworkManager settings for the wireless connection in use
(in my case: /etc/NetworkManager/system-connections/Auto\ godel), and changing all the settings below method=ignore to 'true'. Somehow method=ignore wasn't enough to disable ipv6 lookups.

I agree with Ricardo Fernández and Yermo. This problem is not fixed. I'm still experiencing it in every wireless network i try to connect any of my laptops using ubuntu/kubuntu karmic. Airports, libraries, museums... always the same problem. I've stopped using linux in laptops because of this crap.

I was wondering something, If a Fix was Released, and if it doesn't work (as reported by almost all users since the release), what we should do? Open a new bug ticket?

I'm not changing the status or anything, but it is kinda lame that the status can't be reverted because the fix doesn't work at all. After the Fix was "Released" no one at Ubuntu have been trying to reach the users to see what is going on, they just check that the bug is "fixed" and thats it; is there no need to check the feedback?

This Bug is _NOT_ fixed at all, check the comments from the people, it didn't do the job, they are still delays on resolving names and the browser takes few seconds before opening webpages, this same is happening on 10.04 right now.

I guess this bug will be like the VNC client on Ubuntu (the one installed by default on gnome, vinillo), 4 releases of Ubuntu and still doesn't work at all, no one can even use it, and still there was a "Fix Released".

On Wed, 2010-03-03 at 13:36 +0000, Ricardo Fernández wrote:
> I was wondering something, If a Fix was Released, and if it doesn't work
> (as reported by almost all users since the release), what we should do?
> Open a new bug ticket?

No, you should try to determine if the problem you are experiencing is
the same problem as the problem described in this bug.

If you still have issues (which you shouldn't have, since *this* bug is
fixed), try to debug and find which problem you are experiencing.

This problem is about trying to get AAAA-records on machines that don't
even have any IPv6 connectivity. (devs, please correct me if needed). If
you tcpdump your interface, and see no AAAA-queries, this bug is not
your problem, but there might be another problem.

So, if you still experience issues. Try using wired networks instead of
wireless (I myself have crappy wireless performance with Karmic and a
Linksys interface), tcpdump your interface to see what happens. Etc etc
etc.

> I guess this bug will be like the VNC client on Ubuntu (the one
> installed by default on gnome, vinillo), 4 releases of Ubuntu and still
> doesn't work at all, no one can even use it, and still there was a "Fix
> Released".

I have 3 PCs (1 wired, 2 wireless) on my local home network running Karmic that were all affected by the IPv6 issue described here. The released fix worked for all 3 PCs. There are no more delays - performance is comparable to 9.04, Mandriva with IPv6 turned off, and Windows XP/7. I know of several other folks who had this issue and the fix worked for them as well. My wireless cards are Atheros and Ralink, and my router is a Netgear RP614.

This bug is about Ubuntu dealing with bad DNS servers that don't understand
AAAA (IPv6) queries. Before claiming this isn't fixed, please make sure that
bad DNS servers are in fact the issue. If disabling IPv6 AAAA lookups in
Firefox fixes the issue, then you are dealing with this bug. If switching to
good DNS servers like those of openDNS or Google fixes the issue, then you
are dealing with this bug. If switching from wireless to wired* on the same
LAN* fixes the issue, then you are not dealing with this bug.

Please don't change the status of this bug unless you are sure that you have
issues with IPv6 DNS lookups.
Hilton

--
It's bad civic hygiene to build technologies that could someday be used to
facilitate a police state." -- Bruce Schneier

> I have 3 PCs (1 wired, 2 wireless) on my local home network running
> Karmic that were all affected by the IPv6 issue described here. The
> released fix worked for all 3 PCs. There are no more delays -
> performance is comparable to 9.04, Mandriva with IPv6 turned off, and
> Windows XP/7. I know of several other folks who had this issue and the
> fix worked for them as well. My wireless cards are Atheros and Ralink,
> and my router is a Netgear RP614.
>
> --
> [karmic regression] all network apps / browsers suffer from multi-second
> delays by default due to IPv6 DNS lookups
> https://bugs.launchpad.net/bugs/417757
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eglibc” package in Ubuntu: Triaged
> Status in “network-manager” package in Ubuntu: Invalid
> Status in “eglibc” source package in Lucid: Triaged
> Status in “network-manager” source package in Lucid: Invalid
> Status in “eglibc” source package in Karmic: Fix Released
> Status in “network-manager” source package in Karmic: Invalid
> Status in “glibc” package in Fedora: Confirmed
>
> Bug description:
> In Karmic, DNS lookups take a very long time with some routers, because
> glibc's DNS resolver tries to do IPv6 (AAAA) lookups even if there are no
> (non-loopback) IPv6 interfaces configured. Routers which do not repond to
> this cause the lookup to take 20 seconds (until the IPv6 query times out).
>
> *** PLEASE DO NOT COMMENT ON THIS BUG unless you have something
> constructive to say. Everything that can be said has already been said, and
> if you comment, you are just adding noise. Please let those that actually
> know what they are doing concentrate on fixing this bug from now on. ***
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/+subscribe
>

I had this bug in Karmic, and the fix definitely worked for me. However, I installed Lucid Alpha 3 and the bug is BACK. I know its the same bug because all of the workarounds for Karmic (Firefox disable IPv6, Grub disable IPv6, etc...) fix it in Lucid.

I think people are frustrated because a) this bug is really annoying, b) it took a long time to even acknowledge that it was something that needed fixing, and c) we don't want to see TWO consecutive release version of Ubuntu have unusable internet out-of-the-box.

I don't know if they are related.
This happen with WiFi and Wired cable.

I don't know what else to do to post more info about this bug, and as some other are reported in this same bug we need some directions, in my opinion it isn't Fixed. I don't have this problem in debian, fedora and centos (the other 3 distros i use), it is only happening in Ubuntu 9.10 and 10.04 (Same Laptop, tested with all the other distros), 8.04, 8.10, 9.04 doesn't have this problem.

At least the c1f one does not look like EUI-64 and thus rather like
Windows using IPv6 privacy addresses. For the third line it would be
helpful to see the output of "ip -6 addr", but it's also possible that
it's not the Linux box but another one on the segment.

I disabled IPv6 at the kernel source, make a new kernel without IPv6
at all, and I'm still getting those messages, so my guess is that
those are other machines as you suggest (my home network).

The browsers (any of them, firefox, chrome, epiphany, lynx, elinks)
still takes to much to resolv a name and download the content of it,
apt get stuck sometimes while updating, haven't tried anything else.

Anything else I can do to debug this problem ? so far it seems it is
this bug, but the release fixed doesn't work for me (and all the other
installation I've done over my work network).

@Ricardo Fernández As I mention above, in my case, after disabling IPV6, I still had the same symptoms. Terribly long delays making any kind of network connections (all wired). I noticed here that it seemed to be related to making more than one network connection at a time.

Based on forum posts elsewhere, I upgraded the firmware on my D-Link 707 switch/firewall and then suddenly all network problems disappeared.

Of course, CentOS, WinXP, Win2K and Ubuntu 8.04 never had a problem with the router, so I'm not sure why this fixed the issue.

But unfortunately, I've wasted too much time on Ubuntu 9.10 problems. It's been by far the buggiest least reliable error prone distribution I've ever come across (been developing software using Linux professionally since early 1993). This is also the very first time I've been unable to find good information on how work around issues that come up despite having put in some serious effort. (Sound, anyone?) It's open source after all and I've offered to help track these issues down, but got no useful response.

> @Ricardo Fernández As I mention above, in my case, after disabling IPV6,
> I still had the same symptoms. Terribly long delays making any kind of
> network connections (all wired). I noticed here that it seemed to be
> related to making more than one network connection at a time.
>
>

If disabling IPv6 fixes the issue, you aren't dealing with this bug. Please
open a new one if need be

>> @Ricardo Fernández As I mention above, in my case, after disabling IPV6,
>> I still had the same symptoms. Terribly long delays making any kind of
>> network connections (all wired). I noticed here that it seemed to be
>> related to making more than one network connection at a time.
>>
>>
>
> If disabling IPv6 fixes the issue, you aren't dealing with this bug. Please
> open a new one if need be

What part of "disabling IPv6 doesn't fix this issue" you didn't read?
seriously, I'm starting to get tired of saying this didn't fix the bug
for me, and few others keep saying the same, are you guys really not
reading the posts? Just because the status was changed to "Fixed"
doesn't mean it is really fixed if people are still getting the same
problems.

Please tell me tools to give you more info, tell me what to do to help
the developers to find answers, tell me what do I do need to do to
debug the info you people need.

And don't tell me it is fixed because otherwise i wouldn't be posting
here don't you think ?

Really c'mon guys, why it is so hard? If it is fixed for you, nice!
congratulations! now move along, we have people here that still have
problems (including myself).

No offense, but dealing with Fedora bugzilla and people there is more
easy than dealing with the ubuntu community and developers, here i
have to say around 50 times why it isn't fixed for me and people still
don't belive it, thats just amaizing.

Ubuntu is a nice "end-user-friendly" distribution. I respect what they are trying to do. But there comes a point where bailing is the only sensible option. Fedora Core 12 works like a champ. Networking works. Sound works. Package management works. Java works. OpenOffice works. etc. And I've noticed the same thing you have. The quality of technical posts for Fedora Core is definitely much higher than what I've seen in Ubuntu. I'm not sure why. It's all Linux after all. I guess Fedora attracts a more technical crowd and they seem, at least for the moment, to be much more focused on solving problems.

On Sun, Mar 07, 2010 at 07:01:53AM -0000, Ricardo Fernández wrote:
> What part of "disabling IPv6 doesn't fix this issue" you didn't read?
> seriously, I'm starting to get tired of saying this didn't fix the bug
> for me, and few others keep saying the same, are you guys really not
> reading the posts? Just because the status was changed to "Fixed"
2> doesn't mean it is really fixed if people are still getting the same
> problems.

Conversely, having the same symptoms (and as much as anyone has shown
here since the fix for this bug was verified is that "their network is
slow", which is a very broad symptom) doesn't mean this bug isn't fixed.

You say you've disabled ipv6. How did you do this? Do you have network
traces showing that eglibc is still sending the wrong DNS queries?

I have personally retested the karmic version of libc6 in response to your
message here. The bug described in this report is fixed - a system with no
routable ipv6 addresses will not generate AAAA DNS queries with libc6
2.10.1-0ubuntu16 installed. So whatever problem you're seeing should be
tracked in a separate bug report.

> And don't tell me it is fixed because otherwise i wouldn't be posting
> here don't you think ?

No offense, but experience shows that with high-profile bugs where the
symptom is described in such general terms as is the case here, users *very
frequently* follow up when the problem they're experiencing has nothing to
do with the bug report in question.

> Really c'mon guys, why it is so hard? If it is fixed for you, nice!
> congratulations! now move along, we have people here that still have
> problems (including myself).

If it's fixed for them, then it's almost 100% certain that people still
experiencing problems have a different bug. Different bug -> different bug
report.

(If you're reading this because you *did* file a separate bug and your bug
was marked as a duplicate of this one, then that was a mistake and we should
correct that status. Unfortunately, Launchpad's UI doesn't make it easy to
figure out which commenters in a bug report filed which duplicates, and
encourages users to all follow up to the master bug.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Still getting slow Internet (hardly anything responds), on Karmic (even with OpenDNS -- not a DNS issue!): http://pastebin.org/107680 All tips and pointers appreciated on how to troubleshoot. Frustrating part is, sometimes connections work fine for a while, then all stops responding.

I'm still having this issue. Though I don't think it has to do with ipv6. I've tried every fix I've come across...editing nsswitch, disabling ipv6, open dns, still no luck. I even tried putting another distro on the laptop (arch) and it too suffers the same problem, which makes me think it's an issue with the newer kernel and/or the driver for my particular wireless adapter. No problems at all on jaunty with the same machine.

As you have both a working and a not working configuration, this makes you the perfect candidate for giving more details on that problem. Please give more details: What *exactly* is the problem you are talking about?

Is it a problem while resolving a name to an IP address? (DNS)
Is it a problem connecting to the other host? (Syn, Ack, etc.)
Or is it a problem while beeing connected in some kind of TCP session? (bandwidth, etc.)

If you are not sure, please use wireshark to monitor your connection. (All phases above are visible there and their timing.)
Please do so on the "working" and "not working" system and report the difference.

But since you are pretty sure it has *nothing* to do with IPv6, it is almost certainly another bug.
So *please* open a new bug and give only a pointer to the new bug here.

Hopefully this will finally bring some light on the cause of that issue. :)

Sorry to add to the noise a bit, but I just want to get the scope of this bug clear. I certainly have *a bug* but I can't figure out if it is this one or not. In the description, it says
"If disabling IPv6 or using good DNS servers like openDNS fixes the problem, you are not dealing with this bug."

Does "not dealing with this bug" mean "you have another bug which is unrelated to this", or does it mean "you have this bug, but that isn't a valid fix for it." Maybe we can get this text cleared up to avoid all this confusion about who has the bug and who doesn't.

It also says
"Routers which do not repond [sic] to this cause the lookup to take 20 seconds"

The latter quote seems to imply that the bug will appear for certain DNS servers (e.g., a router), but not others (e.g., proper Internet DNS servers). Therefore, if "using a good DNS server like openDNS fixes the problem", why am I not dealing with the bug? The bug only shows up on certain DNS servers; changing my DNS server is a workaround, but surely it implies I have this same bug.

I have the iiNet BoB router, which is giving me 20 second DNS lookup delays. Changing my DNS settings (in resolv.conf) to a public DNS server (in this case, using my ISP's DNS server) fixes the problem immediately in all apps. So is this the bug, or should I be reporting another one?

Ok, you have a bug. But are you sure it is a bug in Ubuntu?
Do you have any other OS working correctly with the same router?

Please have a look at your network traffic. (Wireshark is nice for this.)

*This* bug goes like this:
Ubuntu: Hey router, what is IPv6 address of example.com?
Router: (ignores that question and does not answer at all)
Ubuntu: (waits for an answer for some seconds and finally...)
Ubuntu: Ok, I assume you don't have one. Then do you have any IPv4 address of example.com?
Router: (answering immediately) Sure, here you are.

With disabled IPv6 Ubuntu does only ask for a IPv4 address and the problem is no longer visible.
If your bug does not go away after disabling IPv6 it is *not* this bug.

Please investigate where your delay comes from. Is it really the router not answering at all? Does it really involve IPv6?
Is there really something Ubuntu can do to fix this? (i.e. are there other OS which do?)

My comment wasn't really to add to the bug report, but mostly to try and clarify the bug's description. I am very confused about whether this is my bug, and the bug description doesn't really help, as it contains a confusing statement which makes me unsure about whether I have the bug.

I understand that this is pretty much a bug in the *routers*, not in Ubuntu. The reason it's reported here on Launchpad and not in a thousand routers is because you're planning to implement a workaround in Ubuntu, right?

What you are saying is, if I switch to another DNS server, then it *may not* be the same bug, but it *might* be (if my router is ignoring IPv6 DNS requests, but the other DNS server is good). But it could be other problems with my router's DNS server besides IPv6.

But if I disable IPv6 entirely, and the bug does not go away, then it is not this bug. (I haven't been able to disable IPv6 yet).

I should have said in my last comment that this bug is new to me in Lucid Beta. It was working fine in Karmic with the exact same setup (same laptop, same router). It works fine in Windows XP. It still works fine with any other router. So it's clearly a combination of this router and Lucid that is a problem *for me*. I'm not asking for help here (since I've already worked around the issue), just trying to figure out if I am having the same bug (so I can be useful, and provide you with socket dumps) or if it isn't (so I can get out of your hair). I will experiment with disabling IPv6 and looking at Wireshark tonight.

Okay. I just gave wireshark a try. I'm not exactly sure what to post, but to be clear on my problem. I click on a random link in my browser and I get a "Waiting for.." dialog in the status. This does not happen every time, but is fairly regular, especially on specific sites, like deviantart.com. Using wireshark during one of these hangs I see a lot of:

[TCP Retransmission] GET....

Then I see the ARP protocol will display [Who has 192.168.1.1 Tell 192.168.1.123] Which is my router IP and Laptop IP respectively.

| I understand that this is pretty much a bug in the *routers*, not in
| Ubuntu. The reason it's reported here on Launchpad and not in a thousand
| routers is because you're planning to implement a workaround in Ubuntu,
| right?

Yes (to both questions).

| What you are saying is, if I switch to another DNS server, then it *may
| not* be the same bug, but it *might* be (if my router is ignoring IPv6
| DNS requests, but the other DNS server is good). But it could be other
| problems with my router's DNS server besides IPv6.

If it works fine with Karmic and works fine with Lucid with IPv6
disabled, but is slow at resolving DNS with IPv6 enabled, that is this
bug. If it's slow with IPv6 disabled, that's really interesting as
well.

| But if I disable IPv6 entirely, and the bug does not go away, then it is
| not this bug. (I haven't been able to disable IPv6 yet).

In grub, add «ipv6.disable=1» after the line with loads the kernel (this
one presumably ends with «quiet splash»).

Can you include the output of running «ip a» in your reply as well?
Preferably both before and after disabling IPv6.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Makes no difference here. Is that still the same patch as
local-ipv6-lookup.diff in karmic-updates?

The only workaround which works fine for me is to change DNS server. I
have a script /etc/network/if-up.d/0nameserver which overwrites
/etc/resolv.conf to use my providers' DNS servers instead of my
router.

| Apparently there is a regression in the ath5k driver affecting my card.
| I was able to fix my problem by using the Windows driver and
| ndiswrapper. Maybe worth a shot for anyone still having problems.

That is another bug than this one; _please_ don't clutter this bug with
reports about hardware and driver problems.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

My apologies, but I only comment on this bug because my original was deleted (marked as a duplicate), and I was automatically (and wrongfully) subscribed to this one. I thought it would be beneficial to share my information with anyone else that was wrongfully subscribed to this bug.

I've noticed multisecond delays since switching to Lucid.
I have two boxes here. Identical resolv.conf entries for local DNS.
The Karmic machine responds instantaneously, the Lucid one takes several seconds for uncached addresses.

And I haven't hit this webserver on our domain recently, I can see it hang for several seconds on getaddrinfo.
It then hangs again resolving the full name (domainwebserver.ourdomain.local) if a redirect is issued.

So far I've tried:
disabling ipv6 in sysctl.conf and as kernel param in grub.
replacing the hosts line in nsswitch.conf w/ only "files dns" (the full hosts line in lucid works fine in karmic).

Uninstalling libnss-mdns.

Despite all this I repeatedly get hangs on getaddrinfo - other things respond quickly, such as dig and nslookup.

The only improvement I've experienced (and this was also new to Lucid) was that after I removed:
mdns4_minimal [NOTFOUND=return] I no longer got complete failure to perform lookups.
That line appears to work fine in Karmic, with the exact same servers.

I've also tried adding or removing wins from the hosts line in nsswitch.conf in case that was why Karmic was fast.
No difference. Whether wins was there or not, Karmic remained fast, and Lucid slow.

FWIW, I spoke too soon, I can only imagine the couple of sites I tested must have been cached by something else hitting 'em on login (ubuntu.com perhaps due to ubuntu one, and local dev site due to a cron). I'm still getting slow lookups :(

BTW. If anyone at all has any idea how to stop Lucid from doing AAAA lookups (besides the many things tried above), that'd be lovely.
Despite all the attempts I've made to disable IPv6 in the comments above, I still get a ton of AAAA lookups from our local DNS.

Hi
Sorry this more just a question
I have been having same/similar problem, Firefox most of the time.. times out... some times I can get google and even use it to search but never go to a web page. and the problem is with Thunderbird also, can not get emails only occasionally, it too times out.
am I the only one with this, is this all related with the ipv6?
O I can use google chrome and Opera with no problems, just Firefox is a problem if that is any help to anyone.
I have the problem with the bata (Which I did te upgrade) and the official release.
again sorry I have no real input, but getting very frustrated with it.
Neil

Neil, I would have e-mailed you privately to not repeat something brought up already in the bug, but you use Hotmail which has some particularly stupid blocking policies so my mail would not have gotten to you.

BTW, I do have ipv6 interfaces after stripping all my ipv4 hacks from above, that seems utterly irrelevant to this finally working.
I of course have no idea what the results of this could be on various apps, but at least the ones I use seem happy.

Are there any updates with regards to this bug? I've been waiting patiently for some kind of fix (I check proposed updates everyday in the hope that there is some mention of this). My system is becoming frankly unusable since 90% of what I do is on the net. I've seen other bugs that have been open for five years or so and I fear that this one is going the same route. No updates whatsoever, even the discussion on this list have stopped.

It's a pity that I'm thinking of installing something else (even a windows 7 installation at this point) even though I've been thoroughly satisfied with 10.04 in all other respects.

if your problem is only in firefox you can disable ipv6: enter about:config in the addressbar and confirm the warning. then enter ipv6 as a filter and double click on network.dns.disableIPv6 (after this the value must be enabled)

flurin & derek: thanks for the information. I'll definitely try the pdns-recursor workaround. the firefox workaround didn't work for me, unfortunately. but i'll try changing the dns and forcing AI_ADDRCONFIG. Lets see what happens.

As for windows 7, I took out my installation CDs for Windows Vista that came with my Lenovo T400. Installation, with all the crap customizations, took about 2 hours? (I just phased out and started playing GTA4 after a certain point). After that the goddamn updates took literally 12 hours (with all the restarts and my 2 MB shared connection). I ended up with a system that booted up in a minute, with a fingerprint reader that didnt work and reintroduced me to the general slowness that drove me to linux in the first place. So now I'm sitting here with lucid back on and checking proposed updates. I have horrible internet, but atleast I don't want to throw my laptop out the window.

By the way, I had a Live CD of openSuse 11.2 lying around (KDE) and I can confirm that I had no issues whatsoever with my internet when I installed that on my system as was the case with Jaunty. Fedora 13 and the latest PCLinuxOS, however, suffer from the same issue. Additionally, the problem is curiously confined only to my internet connection at home and not at work. I initially had the same router (Linksys WRT54G) at home and at work. I changed the one at home thinking that it may have been a router problem and got a DLink Wireless N router instead. That did not work. I have the same ISP at home and work but different modems: a ZyXEL P-600 at work and an Alcatel SpeedTouch Home at home. The modem at home is considerably older then the one at work. Additionally, I have also found that if the internet on my Lucid box is acting up at home, it slows down the internet for everyone else connected to the router. So the lucid lynx is not only managing to annoy me but also other windows users (my wife) as well!

I hope that these workarounds work - Lucid is actually the best OS I've used in a very long time.

It took forever for this to get fixed for Karmic, and now, after upgrading to Lucid, the bug is back. This is absolutely ridiculous. And no, most of us are not in a position to buy a new router or switch ISPs because Ubuntu gets randomly broken with every upgrade.

Well, it is fortunate for me that the code snippet I posted in #288 and #290 worked, because otherwise Ubuntu's pushing forward would have pushed it right off our (large) corporate network.

We have 0 control over that infrastructure. So it was either eliminate the slow and steady introduction of Linux and more open services in general, or find a workaround for this *bug*.

There's ideology, and then there's pragmatism.

It may not work for everyone, but it'd be nice if something equiv to defaulting to AI_ADDRCONFIG without the need for that preload trick was made available in some alternate package that people could add, see if it works for them, and remove once transitions were complete.

Dear Derek, there is a way to fix this problem in your large corporate network, like we did for that small corporate network that I am using: fix the resolvers. As you are claiming to have a large corporate network, you most likely have only a handful of recursors but you might have a 100k clients, lets see which ones are easier to upgrade, 100k clients which are all over the place or that 10 max or so recursors.... easy pick I would say.

The thing you most likely are forgetting is the fact that the DNS recursors that you are using are not only broken for AAAA records, but most likely for every single other address. Thus, by resolving this issue you will solve other magical problems too.
You can directly move on to support DNSSEC too for that matter if you are busy anyway.

Yes, the problem is annoying, no there is not much that Ubuntu or any other OS can do about this. Thus fix the problem in the right spot.

This is where pragmatism comes in.
We have absolutely no control over those resolvers, and even if we had any influence whatsoever with those who did, corporate networks are very slow to change. Ubuntu is the outsider. The Windows machines work. Your solution is not a pragmatic one.

So, while being "pure" is good, I thought Ubuntu stayed out of such things.

I have to agree with Derek. With due respect to all the techs who do the
hard work of keeping Ubuntu (and especially Kubuntu in my case) so
great, I find that, as technical folks, we sometimes get overly focused
on the technical side and forget about the larger world in which that
exists. Sometimes the technically correct solution is not the right
solution in the real world, at least not at first.

Because of all the issues with Karmic, this should have been anticipated
and accounted for in Lucid. By this I mean that clear documentation,
fixes and workarounds should have been provided - if the problem could
not be accounted for silently in code. This problem is a huge hassle for
users who aren't up to speed on the technical side of connecting to the
internet. Those who are may look down on those who are not, but that's
no way to run an operating system.

Derek wrote:
> This is where pragmatism comes in.
> We have absolutely no control over those resolvers, and even if we had any influence whatsoever with those who did, corporate networks are very slow to change. Ubuntu is the outsider. The Windows machines work. Your solution is not a pragmatic one.
>
> So, while being "pure" is good, I thought Ubuntu stayed out of such
> things.
>
> That's why Ubuntu offers easy integration of binary drivers for ATI and
> nVidia, why Ubuntu has a restricted-extras for convenient meta.
>
> Simply because IPv6 is *better* doesn't mean you should sacrifice
> adoption for the ideal.
>
> Using AI_ADDRCONFIG is simple enough, and as noted browsers like Firefox
> and Chrome have adopted that.
>
> What would be nice would be a simple package that forces it across the
> board, simply as an option for broken networks.
>

Thanks Derek. Your patch worked for me. I had already disabled IPv6 via sysctl and took all IPv6 addresses off my interfaces. The about:config solves firefox, but mutt and ssh were still a problem.

I'm a bit surprised at some of the suggested workarounds. I wouldn't really blame the resolvers - things shouldn't be doing AAAA lookups if ipv6 is disabled in the first place. It might be possible to blame the authors of virtually every network-aware app, but that isn't realistic.

Most of us running ubuntu in corporate networks with broken Microsoft resolvers are doing so completely unsupported. If you open a ticket, you'll be lucky if ignoring it is the worst that happens. More likely you'll be told to use a supported environment and just give them another reason why linux users are an expensive problem. "Go fix your resolvers" is just not a reasonable response. Using other DNS servers doesn't work in this case either, because they don't have access the intranet zones.

Well, kind of a good news/bad news situation.
Bad news. A little while ago my solution stopped working for me. Drove me absolutely batty.
I tried all the other things too, disable.ipv6=1 as a kernel parameter, various options in sysctl.conf that used to work, blacklisting any possible modules (not that they were loaded), and of course stripping down nsswitch.conf since all that mdns stuff had always caused unresolvable here.

Heck, I also tried: hints->ai_flags|=AI_ADDRCONFIG; hints->ai_flags|=AI_V4MAPPED; hints->ai_flags&=!AI_ALL;
in my wrapper, even though I have no idea if those would work, and specifying a struct addrinfo newhints; if hints were null.

Anyway.
The happy ending is that recently a 3rd DNS resolver was added. The two broken ones are still broken, but so long as I explicitly specify only the new one in network settings and disable resolv.conf setup from DHCP, I'm fine.

There is no question that the underlying problem here is defective DNS resolvers that choke on perfectly legitimate AAA queries. That said, there are a couple of issues present in software shipped by Ubuntu that cause the problem to manifest itself as slowdowns noticeable by end users:

1) When called with the AI_ADDRCONFIG flag, libc's getaddrinfo() function does not disregard link-local IPv6 addresses when determining whether or not the local host has usable IPv6 connectivity. Since every IPv6-capable OS will have link-local IPv6 addresses assigned to all interfaces - regardless of any external connectivity being available or not - this essentially makes AI_ADDRCONFIG on Linux useless for the purpose of suppressing AAAA queries when they're not useful.

getaddrinfo() on other operating systems (such as Apple Mac OS X and Microsoft Windows) does disregard link-local IPv6 addresses when called with AI_ADDRCONFIG, which is why the problem appears to affect GNU/Linux distributions more than other operating systems.

2) Many applications do not set the AI_ADDRCONFIG flag when calling getaddrinfo(). This includes, notably, Mozilla Firefox. However, a patch to correct this has recently been committed to the mozilla-central developement repo and will likely be part of Firefox 4.0 beta 11 (hopefully also 3.6.15), see <https://bugzilla.mozilla.org/show_bug.cgi?id=614526>. Microsoft Windows enables the use of AI_ADDRCONFIG as the system-wide default, as far as I know, which explains why it is able to cope better with those broken middleware boxes. Mac OS X does not set AI_ADDRCONFIG by default, however it has an extremely short timeout waiting for AAAA responses after the A response has been answered (around 125ms), which in turn hides the problem from most end users. Additionally, most major browsers (except Firefox) do set AI_ADDRCONFIG explicitly, which suppress the problematic AAAA queries in the first place.

So what Ubuntu could to avoid this problem is 1) to develop and include a patch to glibc that makes getaddrinfo() ignore link-local addresses for AI_ADDRCONFIG purposes, and 2) to back-port the NSPR patch already committed to mozilla-central to the version of Firefox shipped (or wait until Mozilla releases a new version with the patch already included).

I totally agree with your solution no 1, which is don't consider link-local
adresses (the ones which start with fe80:: ) as IPv6 adresses that can
resolve AAAA DNS records because that never happen and never will by design

I would be interested if it works for other people.
this is only the way I can use Google earth Firefox & Thunderbird with out changing the ipv6 settings in Ff & T/bird. I can not use earth at all unless I change the nameserver, then all is good.
But I have to do this each time I start up.

FYI, today Mozilla released Firefox 4.0 beta 11, which now calls getaddrinfo() with the AI_ADDRCONFIG flag. You get it from http://www.firefox.com/beta/.

This solves half of the problem. The remaining piece is now to make glibc ignore link-local IPv6 addresses when called with the AI_ADDRCONFIG flag. (This is how all other major operating systems behave already.) I have a bug open in the glibc bugzilla at http://sourceware.org/bugzilla/show_bug.cgi?id=12377 - it would be really great if the Ubuntu glibc developers could help out by writing a suitable patch and attach it to the bug report. I don't think it should be very hard (just extend the already existing logic that ignores loopback addresses). Unfortunately, I'm not much of a programmer myself...

Here's one half of the solution - it's a patch to glibc that makes getaddrinfo() ignore link-local addresses when called with the AI_ADDRCONFIG flag set. This makes getaddrinfo() avoid querying for AAAAs when the host has no IPv6 connectivity, provided that the AI_ADDRCONFIG flag is set.

Here's the second half of the solution. It's a patch that makes Mozilla Firefox use AI_ADDRCONFIG when calling getaddrinfo(). Note that the Mozilla release drivers have already approved this patch for inclusion on the 3.6.x branch, and it has already been commited to Firefox 4.0 (it's included in beta11).

Where, with firefox 5.0, epiphany, chromium some websites take very long time to load, while everything else involving connection is fast. E.g., w3m, lynx and especially elinks are extremely fast! At the same time on!!!! On the

Forgot to mention, that neither disabling ipv6 completely, nor "playing" with the /etc/nsswitch.conf works.
Now since this bug is filed against Karmic, I wonder do I have to make my bug a duplicate? In case if I see it on my machine.

Yet still some problems for me to but I must say only with Google earth and Ubuntu Tweek g/earth wont "connect" and tweek cant get the updates. but if I set sudo gedit /etc/resolv.conf and set the servername to 8.8.8.8 they will work. as I said earlier in comment #312

As you can see, between the AAAA and the A resolution there's a wrong query with my local domain added: this is the one which takes a few seconds to fail (not in this case because I have setup my dnsmasq with local=/internal.eudemo.info/ to get a fast response)
I have tested it with both Firefox and Chrome and both do the same, so I assume is a system problem. Is this the same problem or I need to open a separate bug report (or something is wrong with my setup)?