Closed
Bug 653953
Opened 13 years ago
Closed 8 years ago
https fails (blank page) when accessing IPv6 addressed servers
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bob, Unassigned)
References
()
Details
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ( .NET CLR 3.5.30729) Attempting to browse https://www.arin.net from a WinXP machine running dual stack IPv4 and IPv6 will result in a blank page. The same website works just fine when using IE 8 or IE Tab plus within Firefox, both of which I can confirm access https://www.arin.net using IPv6. I have also confirmed the same problem on another IPv6 website (https://mdp.actusa.net) that uses https/SSL. Reproducible: Always Steps to Reproduce: 1. Must be running a dual stack IPv4 and IPv6 WinXP machine 2. Browse to https://www.arin.net. Make certain that communication is using IPv6 addresses (packet capture to confirm) Actual Results: Blank, untitled page appears. No errors reported. https transport not indicated (no lock or blue security bar). Source of page reveals: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><title></title></head><body></body></html> Expected Results: Should display the https://www.arin.net website page. Browsing of http://ipv6.google.com and other non-SSL IPv6 websites works just fine. Disabling IPv6 DNS (network.dns.disableIPv6 = true) in Firefox will then bring up the https://www.arin.net website. The same problem does not occur using an older version of Firefox 2 on a Sun Solaris 2.8 system also running dual stack IPv4/IPv6. I am able to properly browse any https/SSL website with IPv6.
|
Reporter | |
Comment 1•13 years ago
|
||
This is the packet capture that shows the failed attempt to access https://www.arin.net via IPv6.
|
|
Reporter | |
Comment 2•13 years ago
|
||
Here is a packet capture using IE Tab plus within Firefox of a successful access with IPv6
|
||
Updated•13 years ago
|
Version: unspecified → 3.6 Branch
|
|
Reporter | |
Comment 3•13 years ago
|
||
Same issue also occurs with Firefox 4.0.1
|
|
||
Updated•13 years ago
|
Version: 3.6 Branch → 4.0 Branch
Perhaps this is the same as bug 513659? Can you try a nightly build with that fix and let us know if it fixes your problem? ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
|
|
Reporter | |
Comment 5•13 years ago
|
||
I agree that after reading bug 513659 that I am likely experiencing the same issue - basically the get_peername failure when the receive buffer is >65535. I'd be glad to try a nightly build with the 'fix' however, in perusing the ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ directory there are several versions. Which one has the 'fix'? I have to wonder why doesn't this failure occur with any other browser? IE8, Opera and Chrome all work just fine on the same WinXP SP3 system. Do those browsers 'fix' the receive buffer to 65535 as a work around? Seems odd that the issue only affects FF + IPv6 https on WinXP SP3 systems. I would think that fixing the receive buffer to 65535 would have a detrimental effect on network throughput performance.
Yikes, that nightly directory is a mess. Sorry. Try this page: http://nightly.mozilla.org/
|
|
Reporter | |
Comment 7•13 years ago
|
||
OK, as of yesterday, World IPv6 day it appears that more sites are now using IPv6. It is now becoming obvious that there is a much more serious IPv6 problem with FF v4 than first thought. Basically FF is now failing on more mainstream sites not using https/SSL. First epic fail was a blank page for Facebook using both http://www.facebook.com and https://www.facebook.com. I have attached a wireshark packet captures for both failures. You can see that http access to facebook switches over to https/SSL and that is where the failure occurs which leads one to believe that plain old http IPv6 access is failing even though that is not the case once the packet capture is reviewed. I have confirmed that Facebook loads just fine using IE Tabs in FF, IE8 natively, Safari and Chrome all on the same WinXP system and verified that all other browsers are using IPv6. Interestingly, I didn't have Chrome installed - so using FF I attempted to download it and - another failure. I get to the Google page that says "You're awesome! Thanks for trying Google Chrome!" and - nothing... :-( Another wireshark capture (attached as google-ipv6-failure.pcap) shows that there was a healthy mix of both IPv4 and IPv6 traffic between FF and Google - so it looks like Google as now officially put IPv6 into production. Once I set about:config/network.dns.disableIPv6 = true then I received a download confirmation box and Chrome started to download.
|
|
Reporter | |
Comment 8•13 years ago
|
||
This capture shows what appears top be just a plain IPv6 http website access failing (blank page) yet, you will see that within the session that https/SSL was attempted and that is where the failure really occurs.
|
|
Reporter | |
Comment 9•13 years ago
|
||
This is just a straight IPv6 https/SSL access failure to facebook.
|
|
Reporter | |
Comment 10•13 years ago
|
||
In this capture I was attempting to download Chrome. After Accepting the license agreement, the download should have started. I received the "You're awesome! Thanks for trying Google Chrome!" page but the download did not start. Clicking the 'Click here - if you had trouble downloading.' didn't help. I was not able to download Chrome until I set about:config/network.dns.disableIPv6 = true.
|
||
Updated•11 years ago
|
Component: General → Networking
Product: Firefox → Core
Version: 4.0 Branch → unspecified
|
||
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•