[jaunty] Gnome cannot access Internet (IPv6 ?)

[Jonathan Ernst]

I just do-release-upgraded to jaunty and encountered the following issue after reboot :

I cannot access Internet because name resolution fails in firefox, pidgin, evolution.
However name resolution works using command-line tools (host, dig, ping, etc.)

I changed /etc/resolv.conf to use my isp's dns server instead of my router and not firefox & Co works again (until next reboot when dhcp will put back my router's ip in /etc/resolv.conf).

[Jonathan Ernst (jonathan.ernst)]

Odd, isn't it ?

Is it related with the changes related to ipv6 in the new kernel ?

root@jernst-desktop:~/.scripts# echo "nameserver 192.168.0.1" > /etc/resolv.conf
root@jernst-desktop:~/.scripts# host cern.ch
cern.ch has address 137.138.28.241
cern.ch mail is handled by 10 cernmxgwlb.cern.ch.
root@jernst-desktop:~/.scripts# wget cern.ch
--2009-01-02 20:02:19-- http://cern.ch/
Résolution de cern.ch... échec: Nom ou service inconnu.
wget: unable to resolve host address `cern.ch'
root@jernst-desktop:~/.scripts# echo "nameserver 195.186.1.162" > /etc/resolv.conf
root@jernst-desktop:~/.scripts# host cern.ch
cern.ch has address 137.138.28.241
cern.ch mail is handled by 10 cernmxgwlb.cern.ch.
root@jernst-desktop:~/.scripts# wget cern.ch
--2009-01-02 20:02:47-- http://cern.ch/
Résolution de cern.ch... 137.138.28.241
Connexion vers cern.ch|137.138.28.241|:80... connecté.
requête HTTP transmise, en attente de la réponse... 302 Found
Emplacement: http://user.web.cern.ch/user/ [suivant]
--2009-01-02 20:02:52-- http://user.web.cern.ch/user/
Résolution de user.web.cern.ch... 137.138.140.40
Connexion vers user.web.cern.ch|137.138.140.40|:80... connecté.
requête HTTP transmise, en attente de la réponse... 302 Object moved
Emplacement: http://public.web.cern.ch/public [suivant]
--2009-01-02 20:02:57-- http://public.web.cern.ch/public
Résolution de public.web.cern.ch... 137.138.140.40
Réutilisation de la connexion existante vers user.web.cern.ch:80.
requête HTTP transmise, en attente de la réponse... 301 Moved Permanently
Emplacement: http://public.web.cern.ch/public/ [suivant]
--2009-01-02 20:02:57-- http://public.web.cern.ch/public/
Réutilisation de la connexion existante vers user.web.cern.ch:80.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 15812 (15K) [text/html]
Saving to: `index.html'

100%[=================================================================================================>] 15'812 --.-K/s in 0.04s

[Jonathan Ernst (jonathan.ernst)]

I can resolve ipv6 addresses with both my router and isp's dns too (but cannot access ipv6 websites).

Disabling ipv6 in firefox (about:config, set network.dns.disableIPv6) fixes the issue (in firefox) for me (and pages load visibly faster with my isp's dns too, see Bug #313218).

[Colin Watson (cjwatson)]

Could you please get an strace (with the '-f -s 4096' options) of an offending application? For example, if pidgin is process ID 12345, then 'strace -f -s 4096 -o pidgin.trace -p 12345' while you try to do name resolution, and Ctrl-C when you're finished, would help. Obviously you should make sure that you don't have anything sensitive in the relevant application at the time.

[Colin Watson (cjwatson)]

Or indeed just 'strace -f -s 4096 -o wget.trace wget http://cern.ch/' when your resolv.conf is in a state that makes it break.

[Jonathan Ernst (jonathan.ernst)]

strace -f -s 4096 -o wget.trace wget http://cern.ch/
--2009-01-31 16:51:42-- http://cern.ch/
Résolution de cern.ch... échec: Nom ou service inconnu.
wget: unable to resolve host address `cern.ch'

[Jonathan Ernst (jonathan.ernst)]

And a version in the state where resolv.conf is in a working state :

strace -f -s 4096 -o wget.trace_working wget http://cern.ch/
--2009-01-31 16:57:05-- http://cern.ch/
Résolution de cern.ch... 137.138.28.241
Connexion vers cern.ch|137.138.28.241|:80... connecté.
requête HTTP transmise, en attente de la réponse... 302 Found
Emplacement: http://user.web.cern.ch/user/ [suivant]
--2009-01-31 16:57:05-- http://user.web.cern.ch/user/
Résolution de user.web.cern.ch... 137.138.140.40
Connexion vers user.web.cern.ch|137.138.140.40|:80... connecté.
requête HTTP transmise, en attente de la réponse... 302 Object moved
Emplacement: http://public.web.cern.ch/public [suivant]
--2009-01-31 16:57:10-- http://public.web.cern.ch/public
Résolution de public.web.cern.ch... 137.138.140.40
Réutilisation de la connexion existante vers user.web.cern.ch:80.
requête HTTP transmise, en attente de la réponse... 301 Moved Permanently
Emplacement: http://public.web.cern.ch/public/ [suivant]
--2009-01-31 16:57:10-- http://public.web.cern.ch/public/
Réutilisation de la connexion existante vers user.web.cern.ch:80.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 12003 (12K) [text/html]
Saving to: `index.html'

100%[======================================>] 12'003 --.-K/s in 0.02s

2009-01-31 16:57:10 (615 KB/s) - « index.html » sauvegardé [12003/12003]

[Daniel Stoyanov (dankh)]

I just upgraded to jaunty and I confirm this bug, pidgin refuses to connect to ICQ account. Firefox was unable to resolve almost any url. network.dns.disableIPv6 => true, fixed it. I haven't found yet another applications that reproduce the same problem.

[Les Harris (lesharris)]

I'd like to confirm this on my end as well. Upgrade from Intrepid 64bit->Jaunty exhibits this behavior.

Console tools like ping or links work. Some do not however: notably aptitude and apt-get. My workaround for the apt-get/aptitude issue was to add the ips to us.archive.ubuntu.com and security.ubuntu.com to my /etc/hosts.

Firefox will not work unless network.dns.disableIPv6 is set to TRUE even though I have ipv6 connectivity so it seems its a dns specific issue.

A workaround I have been doing is to add my name servers to /etc/resolv.conf which fixes the issue for all applications but this is sub-optimal as whenever the system releases it's ip I need to readd these servers.

Formerly, having my router supply the dns servers has worked fine (including for ipv6 access) so it seems something peculiar is happening.

[Jonathan Ernst (jonathan.ernst)]

This fixes it for me :

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/313218/comments/47

[Steve Beattie (sbeattie)]

In the similar bug 313218, Colin Watson has a test glibc available in his PPA that may address this issue.He wrote:

  Could people affected by the original problem reported at the top of this bug report please install the libc6
  packages from here:

    deb http://ppa.launchpad.net/cjwatson/ppa/ubuntu jaunty main

  You can find the necessary public key and instructions here:

    https://launchpad.net/~cjwatson/+archive/ppa

  This version of glibc incorporates a patch from Fedora which is said to address a similar-sounding issue,
  and I'd like to confirm whether it also fixes the problems people are encountering here.

  It would be nice if anyone with real IPv6 connectivity could also test this to ensure that I haven't broken
  anything for them. I've had a working IPv6 setup myself in the past, but it's broken at the moment and I
  thought I'd get this out for testing before spending too long trying to fix it.

Thanks!

[Les Harris (lesharris)]

Thanks Steve, Jonathan, and Colin. The patched glibc did the trick. My ipv6 connectivity appears unaffected by the patch, everything just works again. Fantastic!

[Les Harris (lesharris)]

A quick addendum for those trying the same: Until the patch is rolled into the glibc in main don't upgrade your libc6 packages or things will break again.

[Colin Watson (cjwatson)]

Sounds as if this is the same as bug 313218, so I'll mark it as a duplicate. A fix will be available in the main Jaunty archive in a few hours.