Page MenuHomePhabricator

Difficulties reaching IPv6-enabled sites (bugzilla, lists) in Opera, Chrome on some systems
Closed, DeclinedPublic

Description

Got a report from a Linux user of inability to reach Bugzilla in Opera; I was able to reproduce this on my Mac.

Some of our side sites such as:

https://bugzilla.wikimedia.org/
https://lists.wikimedia.org/

are advertising IPv6 addresses in DNS. In at least some circumstances, Opera appears to attempt to connect over IPv6 even if there isn't a functional IPv6 link to the outside internet. (On my Mac, the only working IPv6 around is for the ZeroConf .local network.) The connection fails, but Opera just sort of stalls and gets confused instead of something sensible like falling back to IPv4.

Confirmed problem in Opera 9.54 and 9.63 for Mac.

This newsgroup post describes the issue on WinXP with IPv6 enabled:
http://groups.google.com/group/opera.tech/browse_thread/thread/b2cb34d22a7f8284?pli=1

Would be good if we can make sure this is getting fixed upstream in Opera, or have some standard workaround directions we can provide.


Version: unspecified
Severity: enhancement
URL: https://bugzilla.wikimedia.org/

Details

Reference
bz17140

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:25 PM
bzimport added projects: DNS, Upstream.
bzimport set Reference to bz17140.
bzimport added a subscriber: Unknown Object (MLST).
brion created this task.Jan 23 2009, 10:23 PM

Getting ipconfig / ifconfig output would be useful.

  1. One thing to check if there is a local interface IPv6 address assigned, something like:

fe80::299:77ff:aabb:ccdd

  1. Another check would be whether one has a global IPv6 assigned, like:

2001:0DB8::A01/64 or whatever.

  1. Another check is if you have IPv6 DNS server address in /etc/resolv.conf or ipconfig output on Windows.

If #2 is true, and we have no real IPv6 connectivity, then there is no way for the system to figure out whether you actually have or have not a working global IPv6 (unless to fallback on TCP timeout that application does not have to do really)

If only (1) is true, then getaddinfo(3) invoked with ai_flags |= AI_ADDRCONFIG should be able to find out that
we don't have a working IPv6 connectivity. It would be useful to findout whether:

  • opera uses getaddrinfo(3) at all
  • if yes, does it supply AI_ADDRCONFIG flag

If not, it is quite possible that the IPv4/IPv6 protocol selection logic is simply wrong. Most of the libc implementations use quite complex logic to determine whether IPv6 actually works.

overlordq wrote:

tracert to three hosts (svn/lists/bugzilla)

FWIW I only have problems for the hosts in knams (svn/lists), bugzilla works fine for me.

Attached:

overlordq wrote:

Oops, posted that before I realized this bug was Opera specific. Behavior I posted about above was observed with FF.

brion added a comment.Feb 27 2009, 6:38 PM

On my Mac at the office, I've only got fe80:* local IPv6 addresses. Note that IPv4 has a reserved local address, as this is on a NAT'ed LAN.

IPv6 works on the LAN....

$ ping filesrv1.local
PING filesrv1.local (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=14.417 ms

$ ping6 filesrv1.local
PING6(56=40+8+8 bytes) fe80::21e:c2ff:fea5:98d1%en1 --> fe80::21a:a0ff:fe0e:27bf%en1
16 bytes from fe80::21a:a0ff:fe0e:27bf%en1, icmp_seq=0 hlim=64 time=5.546 ms

But there's no external connectivity via v6:

$ host bugzilla.wikimedia.org
bugzilla.wikimedia.org is an alias for isidore.wikimedia.org.
isidore.wikimedia.org has address 208.80.152.179
isidore.wikimedia.org has IPv6 address 2620::860:2:230:48ff:fe71:5cf6

$ ping bugzilla.wikimedia.org
PING isidore.wikimedia.org (208.80.152.179): 56 data bytes
64 bytes from 208.80.152.179: icmp_seq=0 ttl=46 time=93.758 ms

$ ping6 bugzilla.wikimedia.org
ping6: UDP connect: No route to host

The system seems to be quite aware that there's no v6 route available to the outside; problem seems to be that whatever Opera's doing to connect, it's not figuring out that it should fall back to v4 which does have a perfectly good route. It *should* fail out immediately; there's no need to time out waiting for packets to fail to come back, you just plain don't have a route to send to.

brion added a comment.Jul 12 2009, 7:23 PM

I'm seeing the same with the Google Chrome beta on my MacBook. :(

saper added a comment.Jul 14 2009, 7:46 AM

Brion, can you try to check if 6to4 is working from your office? Opera uses 6to4 by default to connect to IPv6 sites
(I don't know for Chrome).

If this is a 6to4 problem, can you try reaching (traceroute) 192.88.99.1 from your site?

Can you dump your routing table (I think "route -n" should work)?

Also, some samples of traffic sniffed with "tcpdump -s 0 -w file" would be useful (you might want to send those privately)

--Marcin

saper added a comment.Jan 8 2012, 7:40 PM

Might be related to Opera < 10.5 use of 6to4 or teredo instead of IPv4 to reach IPv6 sites. Upgrade should fix it (or enabling Teredo connectivity).

Please reopen if this is still the issue with newer Operas esp. on MacOSX. For other browsers I think we should have a different bug.

Restricted Application added a project: Traffic. · View Herald TranscriptApr 4 2018, 12:50 PM