New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 39830 link

Starred by 11 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug
M-7

Blocking:
issue 32522

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chromium can't connect to ipv6 addresses

Reported by santiago...@gmail.com, Mar 30 2010

Issue description

Chrome Version       : 5.0.364.0 (42891) Ubuntu
URLs (if applicable) : http://[::1]:8888/ (or any other numerical ipv6 
address)
Other browsers tested: Firefox
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x: OK
IE 7:
IE 8:

What steps will reproduce the problem?
1. Set up any ipv6 server (local or remote, http://[2a00:1450:8001::67], 
which is a numerical ipv6.google.com, is good to go)
2. While the above does not load, http://ipv6.google.com loads (in a 
machine with proper ipv6 connectivity)
3. Enjoy. Use a server in http://[::1]/ and call it alternatively as 
http://ip6-localhost/ The latter works, the former does not.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

 

Comment 1 by jar@chromium.org, Apr 2 2010

Status: WontFix
IF your machine does not have global IPv6 connectivity, including a globally visible 
IPv6 address, then Chromium will will disable all IPv6 support.

If you want to experiment with ONLY a local host, and not real IPv6 connectivity, 
then you need to start with a special over-ride command-line flag "--enable-ipv6".  
That will force Chromium to support IPv6 resolutions.

The reason for this "feature" is that many LANs appear to mis-handle an IPv6 
resolution attempt, causing GREAT delays.  The solution was (in such cases where 
there was no IPv6 connectivity) to disable IPv6 resolutions.

If you have a globally visible IPv6 address (such as might be procured from a DHCP 
server, or some static allocation), then Chromium *should* support IPv6 connectivity, 
including to your local host.

Comment 2 by wtc@chromium.org, Apr 2 2010

Labels: -Area-Undefined Area-Internals Internals-Network OS-Linux
jar: you seem to have misunderstood the bug report.  The complaint is that
Chrome cannot connect to a URL that contains an IPv6 address literal.

Comment 3 by jar@chromium.org, Apr 3 2010

Status: Available
Sorry about my misunderstanding.... re-opening
Yeah, two different bugs if what jar says is correct:

- IPv6 literals are not understood (most important one). See the ipv6.google.com
example and bug title
- Can't use IPv6 when not globally connected with ipv6. I was also puzzled that using
ip6-localhost, which is correctly defined in /etc/hosts, failed to get a connection
while it works perfectly with firefox. Is the resolver bypassing /etc/hosts?

Comment 5 by jar@chromium.org, Apr 3 2010

@santiago.gala

We've encountered problems with some LANs, when an attempt is made to resolve an IPv6 
address (and IPv6 is not well supported).  The problem can result in large resolution 
delays..  As a result, we currently disable IPv6 completely when there is no 
interface with an globally visible IPv6 address.  It seemed better to sacrifice the 
ability to set up a private IPv6 localhost, than to cause dramatic performance 
degradation to users that were clueless about this entire issue.  If you, as a 
developer, wish to enable IPv6 so you *can* use a localhost with such an address, 
then you'll need to override our probe, and use --enable-ipv6 as a command line 
argument.  If this happens to cause devastating perf degradation in your external 
browsing, we hope you'll be able to debug the issue.... but it sounds like your LAN 
can deal with this all just fine.

With regard to your detailed example, I don't think we bypass /etc/hosts, rather we 
tell the resolver (when we decide not to use IPv6) to ONLY use IPv4.  That would 
probably cause your IPv6 address in /etc/hosts to be ignored.

Hopefully that makes sense.

Again, sorry for misreading the more important issue in your bug.

Comment 6 by wtc@chromium.org, Apr 5 2010

Labels: Mstone-6 HelpWanted
It seems to be working as of 5.0.368.0 (43430) Ubuntu
@santiago.gala: if you think it is an issue with resolving of IPv6 literals, go to:
   chrome://net-internals/hostresolver.hostcache

And paste the resulting entries. (Note that IP literals will have their own entry too, since they get run through 
getaddrinfo() just the same).

Comment 9 by gavinp@google.com, Apr 7 2010

I've been doing some fixing on 35050 (make ftp on ipv6 work), and I have found some interesting information in 
the hostcache for ipv6 literals.

I have three machines, let's call them Win, Mac, and Nux.  At Mac, I enter 

http://[Mac]/
ftp://[Nux]/

the host cache (pasted from about:net-internals) now looks like this:

Mac	UNSPECIFIED	2620::1004:1:225:ff:fef2:d881	36600
[Nux]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-166441
[Mac]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-25097

(also note, the http request to Mac succeeds, the ftp to Nux fails, and a packet sniffer shows no outbound packets 
whatsoever to Nux).

Do the same thing on Win, and I get slightly different behaviour.  The resolver looks like:

Mac	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	50615
[Nux]	UNSPECIFIED	2620:0:1004:1:21e:c9ff:fe47:43f4	-1011241
[Mac]	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	16302

Notice that the [hostnames in square brackets] resolved on windows?  Interesting!  A packet sniffer running on Nux 
shows an FTP control session start from Win --> Nux, then die when the requesting chrome uses PASV to request a 
transfer, when of course EPSV is right for ipv6.  But that's my issue, not the instant one.

On Linux, things look more like the mac:

Mac	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	6348
[Nux]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-16703
[Mac]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-54488

See, the [Hostnames] didn't resolve.

All in all very interesting.  However, in every case, I found ipv6 literals worked fine from my browser as long as I 
didn't use our networks squid proxy server (which sometimes, and unpredictably, broke ipv6).








Regarding comment #9, that is a bug in ftp_network_transaction.cc:

  host = request_->url.host(); 
  port = request_->url.EffectiveIntPort();

Really it should be doing

  host = request_->url.HostNoBrackets();
  port = request_->url.EffectiveIntPort();

(HttpNetworkTransaction is careful to do this, to avoid exactly this problem).

I can fix that issue.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=43888 

------------------------------------------------------------------------
r43888 | eroman@chromium.org | 2010-04-07 15:41:58 -0700 (Wed, 07 Apr 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ftp/ftp_network_transaction.cc?r1=43888&r2=43887
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ftp/ftp_network_transaction_unittest.cc?r1=43888&r2=43887

Make sure to strip the brackets around IPv6 literals when resolving the hostname for FTP.

BUG= 39830  (comment #9)
TEST=FtpNetworkTransactionTest.StripBracketsFromIPv6Literals

Review URL: http://codereview.chromium.org/1585022
------------------------------------------------------------------------

Status: Assigned
Not sure if it is related, but I'm seeing something strange lately: while 
disconnected, I can't access localhost, localhost.localdomain or even 127.0.0.1, even 
when there is route and processes listening there. I guess this is a bug, is it? 
getaddrinfo works exactly the same with localhost or 127.0.0.1 either connected or 
disconnected...

# Using python while disconnected with and without AI_CANONNAME
>>> import socket
>>> socket.getaddrinfo("127.0.0.1", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP)
[(2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("127.0.0.1", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(2, 1, 6, '127.0.0.1', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP)
[(10, 1, 6, '', ('::1', 8080, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(10, 1, 6, 'kurtz', ('::1', 8080, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost.localdomain", 8080, 
socket.AF_UNSPEC,socket.SOCK_STREAM, socket.IPPROTO_TCP)
[(2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost.localdomain", 8080, 
socket.AF_UNSPEC,socket.SOCK_STREAM, socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(2, 1, 6, 'kurtz', ('127.0.0.1', 8080))]

Re #8 I already said that it is working now in #7. I think it got fixed in some change 
between the revision I reported against, 5.0.364.0 (42891) Ubuntu and the revision I 
tested later: 5.0.368.0 (43430)
Labels: -Mstone-6 Mstone-7

Comment 17 by evan@chromium.org, Aug 11 2010

Is this fixed, then?
Status: Started
I have a CL pending to fix it: http://codereview.chromium.org/3023048
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56385 

------------------------------------------------------------------------
r56385 | vandebo@chromium.org | 2010-08-17 11:00:02 -0700 (Tue, 17 Aug 2010) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/predictor_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.h?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_unittest.cc?r1=56385&r2=56384

Revert 56384 - Don't resolve IP literals.

For each resolution request this checks to see if this 'host' is a literal ip address.  If so, it synthesises a struct addrinfo and returns it without adding it to the cache.

BUG= 39830 
TEST=unit tests, new and old

Review URL: http://codereview.chromium.org/3023048

TBR=vandebo@chromium.org
Review URL: http://codereview.chromium.org/3115014
------------------------------------------------------------------------

Status: Fixed
Project Member

Comment 23 by bugdroid1@chromium.org, Oct 12 2012

Blocking: -chromium:32522 chromium:32522
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Mstone-7 M-7 Cr-Internals Cr-Internals-Network
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 26 by bugdroid1@chromium.org, Aug 1 2014

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=179409

------------------------------------------------------------------
r179409 | enne@chromium.org | 2014-08-01T17:59:04.799449Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/TestExpectations?r1=179409&r2=179408&pathrev=179409
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/SlowTests?r1=179409&r2=179408&pathrev=179409

Mark before-unload-return-bad-value as timing out

TBR=rjwright@chromium.org
NOTRY=true
BUG= 39830 

Review URL: https://codereview.chromium.org/439523002
-----------------------------------------------------------------

Sign in to add a comment