** Changed in: glibc (Fedora)
Status: Confirmed => Fix Released
** Changed in: glibc (Fedora)
Importance: Unknown => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/417757
Title:
Right, closing the floating task.
** Changed in: eglibc (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/417757
Title:
[regression] all network apps /
@doko, this ticket is marked as fix released even for karmic, yet
remains in an open state for the development release. Is there anything
left to do?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
lucid has seen the end of its life and is no longer receiving any
updates. Marking the lucid task for this ticket as Won't Fix.
** Changed in: eglibc (Ubuntu Lucid)
Status: Triaged = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
oops, that late_command doesn't work, but you get the picture. It's
missing in-target, but I'm not sure if I can in-target redirect.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/417757
Title:
In the hope that this helps someone. I spent most of today fighting
this and found a solution.
d-i preseed/early_command string grep -q options /etc/resolv.conf ||
echo options single-request /etc/resolv.conf ;
and then
d-i preseed/late_command string grep -q options
** No longer affects: network-manager (Ubuntu)
** No longer affects: network-manager (Ubuntu Karmic)
** No longer affects: network-manager (Ubuntu Lucid)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I would like to add new information and research that has been done in
the Fedora project:
https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
It links to related fedora bug reports which in turn link to upstream
bug reports. It contains enough information about what is required
This LinkedIn invitation is a bit odd : Bug can't reply to you :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/417757
Title:
[regression] all network apps / browsers suffer from multi-second
New patches have been proposed a few days ago on redhat's bugtracker at
https://bugzilla.redhat.com/show_bug.cgi?id=505105
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/417757
Title:
[regression]
Stéphane, the same patch was posted in this bug as well, see comment
#316. (The one in #317 is no longer necessary, as it's been included in
the NSPR upstream code for a long time now.)
Tore
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I'm not sure if this is the same bug I'm experiencing, but if I try to
access a domain without IPv6 address, I get this on tshark:
0.00 192.168.2.103 - 192.168.2.254 DNS 74 Standard query
one.ubuntu.com
0.074500 192.168.2.254 - 192.168.2.103 DNS 135 Standard query response
I have this issue with ssh in Ubuntu 11.10. Installing the power-dns
resolver as mentioned in an earlier comment worked for me.
To install pdns-resolver, I I set my nameserver to 127.0.0.1 in
/etc/resolv.conf and followed these instructions:
Unbelievable, this bug still manages to bug people on the latest and fully
updated Ubuntu 11.04!
The strangeness of the situation is as follows:
ubuntu 11.04, uname -a:
Linux 3.0.0-mine #3 SMP Thu Jul 28 14:03:44 CDT 2011 i686 i686 i386 GNU/Linux
Where, with firefox 5.0, epiphany, chromium
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.
--
You received this bug notification because you are a
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
--
You received this bug
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
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
s when the host has no IPv6 connectivity, provided that the
AI_ADDRCONFIG flag is set.
Tore
**
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
Hello,
Neil [2011-02-01 7:32 -]:
I would be interested if it works for other people.
Yes, for me as well.
But I have to do this each time I start up.
I created a script for that:
$ cat /etc/network/if-up.d/0nameserver
#!/bin/sh
grep -q Speedport_W_303V_Typ_B /etc/resolv.conf || exit
change: nameserver 10.1.1.1 (numbers maybe different on yours)
to: nameserver 8.8.8.8 and then save.
I think this is just switching from your ISP's to Google's DNS server.
Admittedly many ISPs' servers are broken, but changing the default
warrants more discussion.
--
You received this bug
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
At last nomebody has understood the problem ! Well done !
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 DNS records because that never happen and never will by design
--
You
I'm glad to see it's not just me having this problem still.
I was give this little fix and works great. maybe a help, for give me if this
has been posted already, there is a lot to read though.
sudo gedit /etc/resolv.conf
change: nameserver 10.1.1.1 (numbers maybe different on yours)
to:
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
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
Hi, Folks.
I set up the function getaddrinfo() as specified in #288 #290 above,
but then lost connectivity to Samba shares on other machines in the
local LAN.
When I commented-out the line /usr/local/lib/getaddrinfo_wrap.so in
the file /etc/ld.so.preload, instantly my Samba shares returned.
Yeah, dunno what to say. WFM w/ my samba shares.
mount.cifs //intranetdev/wwwroot /home/nemo/Shares/intranet
That sorta thing.
Guess you're out of luck on that fix. Here's hoping something else
works. Sorry.
--
[regression] all network apps / browsers suffer from multi-second delays by
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 -
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.
--
[regression] all network
On the contrary, Ubuntu is not a position to deviate from pushing
forward with IPv6 just because some of you have broken hardware.
--
[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
Jeremy. Member of the IPv6 taskforce eh.
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
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
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,
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.
hello,
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
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
Also what I don't understand is why DOCKY bugs are assigned as
critical in the ubuntu bug list but this one is only of 'high'
importance!
--
[regression] all network apps / browsers suffer from multi-second delays by
default due to IPv6 DNS lookups
https://bugs.launchpad.net/bugs/417757
You
omair: did you try the pdns-recursor workaround?
maybe this can help you until there is a fix.
install pdns-recursor via synaptic or apt-get.
then edit /etc/resolv.con (sudo gedit /etc/resolv.conf) and set nameserver to
127.0.0.1
if your problem is only in firefox you can disable ipv6: enter
For me using openDNS works fine as a workaround.
--
[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 Ubuntu
Bugs, which is subscribed
omair, if you can't change your DNS, I've found that forcing AI_ADDRCONFIG as
noted in #288, #289 and (importantly) #290
works nicely for me.
Also, if it causes trouble for you, you can just remove or comment out
the ld.so.preload line.
I've applied it on 5 computers here at work w/ no issues
http://sourceware.org/bugzilla/show_bug.cgi?id=4599
This is kind of related to the last few comments. If you decide to
force AI_ADDRCONFIG, until those fixes are in place, you should watch
out for IPv6 in your hosts file.
** Bug watch added: Sourceware.org Bugzilla #4599
oh, and that came from:
https://bugzilla.mozilla.org/show_bug.cgi?id=467497#c9
and the following two comments.
I do wish Launchpad allowed anchors to comment numbers in the context of
the whole page
--
[regression] all network apps / browsers suffer from multi-second delays by
default due to
FYI, I changed:
hints-ai_flags|=AI_ADDRCONFIG;
to
if(hints) hints-ai_flags|=AI_ADDRCONFIG;
For obvious reasons :-/
--
[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
I think I've finally fixed things to my satisfaction, system-wide:
$ cat getaddrinfo_wrap.c
// getaddrinfo wrapper
#include dlfcn.h
#define getaddrinfo _foo
#include netdb.h
#undef getaddrinfo
int getaddrinfo(const char *node, const char *service, struct addrinfo *hints,
struct addrinfo **res)
With regards to Firefox, see also:
https://bugzilla.mozilla.org/show_bug.cgi?id=467497
--
[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
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.
Firefox, go to the url about:config
Search for:
network.dns.disableIPv6
And set to
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.
Have also tried:
[ipv6]
method=ignore
ignore-auto-routes=true
ignore-auto-dns=true
never-default=true
In network manager config and options single-request in resolv.conf
Nothing seems to stop it from trying despite ip -6 reporting no
ipv6 routes or interfaces.
BTW. If anyone at all has any idea how to stop Lucid from doing 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 lookups from our local DNS.
Karmic? All A.
--
[regression]
I confirm that this bug is back in Lucid RC ...
** Summary changed:
- [karmic regression] all network apps / browsers suffer from multi-second
delays by default due to IPv6 DNS lookups
+ [regression] all network apps / browsers suffer from multi-second delays by
default due to IPv6 DNS lookups
51 matches
Mail list logo
