Unable to access https://www.google.com/?safe=active&ssui=on
Reported by
nsamarak...@gmail.com,
Oct 13 2016
|
|||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Example URL: https://www.google.com/?safe=active&ssui=on Steps to reproduce the problem: 1. Open latest stable version of Chrome - 54.0.2840.59 (Official Build) m (64-bit) for Windows 2. Navigate to https://www.google.com/?safe=active&ssui=on 3. User experience is "This site can’t be reached The webpage at https://www.google.com/?safe=active&ssui=on might be temporarily down or it may have moved permanently to a new web address. ERR_QUIC_PROTOCOL_ERROR" 4.Open new tab and navigate to https://www.youtube.com/. Site loads correctly. What is the expected behavior? Google homepage should load correctly. What went wrong? See attached image. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 53.0.2785.143 Does this work in other browsers? Yes Chrome version: 54.0.2840.59 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 23.0.0.185 Tried on Mac with same latest stable version 54 and I was able to access https://www.google.com/?safe=active&ssui=on. Did not try on Linux.
,
Oct 14 2016
Unable to reproduce this issue on Windows 7,Mac 10.11.4,Linux Ubuntu 14.04 with Chrome version -54.0.2840.59 and latest canary. Please find the screencast for reference . Please verify the same by creating a new profile and let us know if i miss anything to address this issue. Thanks.
,
Oct 14 2016
I am able to re-produce this problem on multiple workstations running Windows 7, 8.1, and 10 64bit. The following steps are for Windows 8.1 1. Connect to Windows 8.1 workstation that has Google Chrome version 53.0.2785.143. 2. Navigate to https://www.google.com/?safe=active&ssui=on. The site loads correctly. See attached. 3. Open a new tab and goto chrome://help/. This will invoke a force update. 4. Relaunch Chrome and verify updated version to 54.0.2840.59. 5. Navigate to https://www.google.com/?safe=active&ssui=on. The Site does not load. See attached.
,
Oct 14 2016
The following steps were done on a Windows 10 workstation. 1. Remove Google Chrome. 2. Delete Google Chrome profile date from ~/usr/ folder. 3. Download Google Chrome for Work 64bit MSI from https://enterprise.google.com/chrome/chrome-browser/ 4. Install package. 5. Launch Google Chrome and navigate to https://www.google.com/?safe=active&ssui=on. The site loads correctly. See attached. So that leads me to believe that something resulting from a manual update from Google Chrome 53.0.2785.143 (using chrome://help/) to Google Chrome 54.0.2840.59 maybe at fault. We have approx 300K workstations running Google Chrome 53.0.2785.143 today. It is would be impracticable to ask the organization to remove existing version (53.0.2785.143) and clean install 54.0.2840.59. We have Google auto-update in place to get the latest stable release on all workstations. So this problem must be fixed ASAP. Can you kindly look in to why manual update is causing this problem on 64bit Windows environment?
,
Oct 14 2016
Here is the net-internal output from the Windows 8.1 workstation where I can re-produce this problem.
,
Oct 14 2016
Definitely not blink.
,
Oct 15 2016
Based on comments from other users experiencing this same problem - Joseph Tikalsky mentioned that by Disabling Quic Protocol from chrome://flags solves the issue. See https://googlechromereleases.blogspot.com/2016/10/stable-channel-update-for-desktop.html#gpluscomments. I tried it and it worked. Now I am able to access the site. Please work on resolving this problem ASAP and consider removing v54.x from Stable release (until a proper fix is in place).
,
Oct 17 2016
We are having the same problem. The QUIC protocol is blocked by the corporate firewall. After v54 upgrade none of the Google services are working anymore. Chrome refuses to default back to TCP. We had to manually disable QUIC. Other people are complaining about the same issue. https://productforums.google.com/forum/#!topic/chrome/f6lOszUBxKo;context-place=forum/chrome https://productforums.google.com/forum/#!topic/chrome/IU_1jwpnKQk Thank you!
,
Oct 17 2016
Chrome team: It doesn't make sense to say that Firewall rules are at play with QUIC protocol - esp given that removing previous installations of Chrome and installed v54 seems to work - with no changes to FW.
,
Oct 17 2016
I have looked at the net-internals in comment 5. Chrome is able to communicate with the server for the first second of the connection, then it appears that connectivity is lost. When we have seen this is the past, this has been NATs/Firewalls which are not playing well with QUIC. nsamarakkody@gmail.com: What ISP are you using? Do you know what router and firewall you're using?
,
Oct 17 2016
vince_daicu@googleapps.wrdsb.ca: You mentioned your firewall blocks QUIC, but that chrome is failing to fall back to TCP. We tested this configuration and have not been able to reproduce the problem. Can you collect a net-internals trace to help us understand what is happening? https://dev.chromium.org/for-testers/providing-network-details Also, do you know what model of firewall you're using?
,
Oct 17 2016
See net-internals log from nsamarakkody@gmail.com, Oct 14 (2 days ago). This is with QUIC set to Default. I also captured net-internals logs after disabling QUIC from flags. See nsamarakkody@gmail.com, Oct 15 (2 days ago)
,
Oct 17 2016
nsamarakkody@gmail.com: You mentioned in comment 1 that the 32 bit version of Chrome does not have the problem. That's very interesting. Are you able to collect a net-internals trace with 32 bit chrome from the same computer that the 64 bit version is not working on?
,
Oct 17 2016
re comment 12: nsamarakkody@gmail.com, do I understand you correctly to be saying that the trace in comment 5 comes from an environment in which the firewall is configured to block QUIC traffic? If so, can you say more about how this is happening? Usually such firewalls block all traffic on UDP port 443 but that does not seem to be the case from looking at net-internals.
,
Oct 17 2016
RCH: No, I am not saying that FW is blocking. If that was the case then clean install of Chrome v54 would also be the same (block). See my comment #9. I am working on getting a log from a 32bit.
,
Oct 17 2016
Great, thanks!
,
Oct 17 2016
Correction The problem can be reproduced on 32bit OS as well. Here are the net-internal pre-upgrade (53.0.2785.143) and post-upgrade (54.0.2840.59).
,
Oct 17 2016
Hi. I'm looking at the Chrome 53 trace and I don't see any QUIC attempted at all. Obviously, QUIC can't fail when it's not enabled. Here's one difference I see between your Chrome 53 and Chrome 54 net-internals: Chrome 53: QUIC Enabled: false Chrome 54: QUIC Enabled: true
,
Oct 17 2016
That's interesting. QUIC is enabled, typically, via "field trials". In your M53, can you visit chrome://version/ and tell me what you see for "Variations"? Also, can you run M53 with --enable-quic and see if you see problems?
,
Oct 17 2016
Google Chrome 53.0.2785.143 (Official Build) m (64-bit) Revision f33d44362232c20d1ce2111c53ea8730698f3c88-refs/branch-heads/2785@{#925} OS Windows Blink 537.36 (@f33d44362232c20d1ce2111c53ea8730698f3c88) JavaScript V8 5.3.332.47 Flash 23.0.0.185 User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Command Line "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end Executable Path C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Profile Path C:\Users\I281936\AppData\Local\Google\Chrome\User Data\Profile 1 Variations 6a89113b-a7aa8ed b3888d8d-afba0f91 6345b824-3d47f4f4 7c1bc906-f55a7974 ba3f87da-ca7d8d80 f049a919-3f4a17df f15c1c09-ca7d8d80 93731dca-3f4a17df 9e5c75f1-c16ec2e6 f79cb77b-3d47f4f4 b7786474-d93a0620 868bda90-ca7d8d80 4ea303a6-a809ae20 7aa46da5-8279be7 9736de91-ca7d8d80 dbffab5d-ca7d8d80 6844d8aa-669a04e0 f47ae82a-746c2ad4 3ac60855-486e2a9c f296190c-38939ee9 4442aae2-e1cc0f14 ed1d377-e1cc0f14 75f0f0a0-4ad60575 e2b18481-7158671e e7e71889-4ad60575 828a5926-ca7d8d80 Compiler MSVC 2015
,
Oct 17 2016
Sorry to keep asking questions. Can you also send a net-internals from that M53 instance?
,
Oct 17 2016
Here is the log file with QUIC enabled on M53.
,
Oct 17 2016
I don't see an attachment. Did you mean to include one?
,
Oct 17 2016
Well now https://bugs.chromium.org is down. I will attach as soon as the site is up.
,
Oct 17 2016
Doh! You can use https://monorail-prod.appspot.com/p/chromium/issues/detail?id=655846 in the mean time. Sorry for the outage.
,
Oct 17 2016
Here is the log file with QUIC enabled on M53. Thanks.
,
Oct 17 2016
OK, this is super confusing! In the M53 net-internals, QUIC sessions never receive any packets from the server. But in your M54 traces, QUIC sessions *do* received packets from the server. This is perplexing. Can you try running M54 with the --quic-version=QUIC_VERSION_34 command line argument?
,
Oct 17 2016
Here is the log from running --quic-version=QUIC_VERSION_34 command line
,
Oct 17 2016
Interesting! It looks like things are working smoothly in that log. Is that what you saw as well?
,
Oct 17 2016
Still unable to access: This site can’t be reached The webpage at https://www.google.com/?gws_rd=ssl&safe=active&ssui=on might be temporarily down or it may have moved permanently to a new web address. ERR_QUIC_PROTOCOL_ERROR
,
Oct 18 2016
Ah, yes, you're right. I think I must have opened a different file. Sorry for the confusion. So this seems to confirm that *Something* is different between M53 and M54 which is manifesting as the no packets being received from the server after the first couple round trips in M54 but in M53 *no* packets are received. jri/jokulik: any ideas what might be going on here? nsamarakkody@gmail.com: Do you know what ISP/router/firewall you happen to be using?
,
Oct 18 2016
Company network. No idea about FW/Router device info. Verizon provides network services (I think). Sorry.
,
Oct 18 2016
One more possibility tonight, can you run M54 with --quic-connection-options=FIXD and see if that happens to fix things? It seems unlikely, but it is one difference between 54 and 53.
,
Oct 18 2016
This definitely seems like a middlebox that was completely blocking QUIC earlier, but is unable to with M54. Is there any more information you can give us about the network service provider? (We can reach out to them directly as well and find out, but I think I'd need more information about your particular service before reaching out to them. Please feel free to write directly to me and rch if you'd rather not discuss those details on this bug.)
,
Oct 18 2016
On #34, I think Ryan meant to ask about running M54 with QUIC version 34 and FIXD, that is: --quic-version=QUIC_VERSION_34 --quic-connection-options=FIXD
,
Oct 18 2016
Also, do you know if you're running any sort of anti-virus software? If so, what is it?
,
Oct 18 2016
Log file with --quic-version=QUIC_VERSION_34 --quic-connection-options=FIXD Output is the same: The webpage at https://www.google.com/?gws_rd=ssl&safe=active&ssui=on might be temporarily down or it may have moved permanently to a new web address. ERR_QUIC_PROTOCOL_ERROR
,
Oct 18 2016
McAfee Host Intrusion Prevention
Version number: 8.0
Build date: Friday, August 19, 2016
Build Number: 8.0.0.3250
License Type: Licensed
Expiration Date
Language: Automatic
Security Content Version: 8.0.0.7245
Security Content Created On: Friday, September 09, 2016
Patch: 5
McAfee Agent
Version number: 5.0.3.316
McAfee Policy Auditor Content Update
Version number: 6.2.0.231
Language: Multiple
McAfee Policy Auditor
Version number: 6.2.0.231
Language: Multiple
System Information Reporter
Version number: 1.0.0.199
Language: English (United States)
McAfee SiteAdvisor Enterprise
Version number: 3.5.0.1195
Language: Multiple
Service Pack
Version: 2
Install Date: 1/14/2015 1:38:21 PM
McAfee Policy Auditor Agent
Version number: 6.2.0
Build date: 09/05/2013
McAfee VirusScan Enterprise + AntiSpyware Enterprise
Version number: 8.8.0 (8.8.0.1247)
Build date: 1/16/2014
Anti-virus License Type: licensed
Scan engine version (32-bit): 5800.7501
Scan engine version (64-bit): 5800.7501
DAT version: 8321.0000
DAT Created on: 10/17/2016
Number of Signatures in extra.dat: 0
Name of threats that extra.dat can detect: None
Buffer Overflow and Access Protection DAT version: 659
Installed Patches: 4
Installed Modules:
Copyright © 1995-2016 McAfee, Inc.
All Rights Reserved.
www.mcafee.com
,
Oct 18 2016
No joy on FIXD, rats. Is it possible for you to turn of your AV software and see if that changes anything? We've seen instance in the past where AV software causes problems with Chrome networking code.
,
Oct 18 2016
In enterprise network basically new updates pushed via SCCM tool and we pushed on customer network 54.0.2840.59 and we have recieved around 20 odd cases related to this and still users reporting. request to fix this asap.
,
Oct 18 2016
rch@chromium.org Comment 40: It is impossible to get AV disabled on any workstation. Sorry. I did a clean install of Chrome M54 and collected this log. This time, even the clean install did not have a positive outcome.
,
Oct 18 2016
It looks like M54 also contains changes to the connection ID length flags in the public header. Can you try running M54 with --quic-version=QUIC_VERSION_32 (v43 does not have this change).
,
Oct 18 2016
Oh, rats, I take it back, that's not expected to work server side :/
,
Oct 18 2016
nsamarakkody@gmail.com: Ok, I've tried to build a special version of chrome with this flag flipped in the packet header. You should be able to download a zip here. you *should* be able to unzip it and run out/Release_x64/chrome.exe --enable-quic https://drive.google.com/file/d/0B0slsTGqC-scU0FHdVNBYWViVjA/view?usp=sharing
,
Oct 18 2016
Special version worked. Here are log files from Win 10 and 8.1 workstations.
,
Oct 18 2016
GREAT! Thanks, this is good progress.
,
Oct 18 2016
,
Oct 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb commit a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb Author: Ryan Hamilton <rch@chromium.org> Date: Tue Oct 18 21:59:19 2016 Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=jri@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Cr-Commit-Position: refs/heads/master@{#426066} [modify] https://crrev.com/a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb/net/quic/core/quic_flags_list.h [modify] https://crrev.com/a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb/net/quic/core/quic_framer.cc [modify] https://crrev.com/a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb/net/quic/core/quic_framer_test.cc
,
Oct 18 2016
,
Oct 18 2016
Awesome, thanks! Approved for M54
,
Oct 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cdd00e9c828ed19aff3c6baca623dd7153caee0a commit cdd00e9c828ed19aff3c6baca623dd7153caee0a Author: Ryan Hamilton <rch@chromium.org> Date: Tue Oct 18 22:23:50 2016 [Merge m54] Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=jri@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Review URL: https://codereview.chromium.org/2429993002 . Cr-Original-Commit-Position: refs/heads/master@{#426066} Cr-Commit-Position: refs/branch-heads/2840@{#752} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/cdd00e9c828ed19aff3c6baca623dd7153caee0a/net/quic/core/quic_flags.cc
,
Oct 19 2016
Tried the issue following the below steps and did not find any issues. On Windows 7: -------------- 1) Installed 54.0.2840.59 at System level 2) Opened chrome from Cygwin(QUIC enabled) 3) Opened below urls https://www.google.com/?safe=active&ssui=on youtube.com, soundcloud.com & join.me 4) Updated chrome running updater file 5) Navigated chrome://help (opened from Step 3) 6) Relaunched for updating to 54.0.2840.68 7) Observed no issues. Note : Repeated the above steps for 53.0.2785.143 and updating to 54.0.2840.59 & 54.0.2840.68, did not find any issues. On Mac 10.11.6 & Ubuntu 14.04 ------------------------------ Over-installed chrome on top of 54.0.2840.59, and did not observe any issues. rch@ : Could you please confirm on this if the repro steps are correct.
,
Oct 19 2016
,
Oct 19 2016
Issue 655763 has been merged into this issue.
,
Oct 19 2016
,
Oct 19 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Oct 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272 commit ef8417b1baf6251d9e47fc8b7eb84ffb34e67272 Author: Ryan Hamilton <rch@chromium.org> Date: Thu Oct 20 00:35:50 2016 [m55 merge] Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=jri@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Cr-Commit-Position: refs/heads/master@{#426066} (cherry picked from commit a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb) Review URL: https://codereview.chromium.org/2437913002 . Cr-Commit-Position: refs/branch-heads/2883@{#203} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_flags_list.h [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_framer.cc [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_framer_test.cc
,
Oct 20 2016
Issue 657644 has been merged into this issue.
,
Oct 21 2016
Issue 657050 has been merged into this issue.
,
Oct 21 2016
,
Oct 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9b9fe325c47b422505463c184e7d76034a942e33 commit 9b9fe325c47b422505463c184e7d76034a942e33 Author: Misha Efimov <mef@chromium.org> Date: Fri Oct 21 19:02:34 2016 [Merge to 2881 for release cherry-picking] Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=rch@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Cr-Commit-Position: refs/heads/master@{#426066} (cherry picked from commit a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb) Review URL: https://codereview.chromium.org/2442833003 . Cr-Commit-Position: refs/branch-heads/2881@{#8} Cr-Branched-From: 6b08cd23a5bbe4e1d95bb7e0431fc743e6b0180c-refs/heads/master@{#423030} [modify] https://crrev.com/9b9fe325c47b422505463c184e7d76034a942e33/net/quic/core/quic_flags_list.h [modify] https://crrev.com/9b9fe325c47b422505463c184e7d76034a942e33/net/quic/core/quic_framer.cc [modify] https://crrev.com/9b9fe325c47b422505463c184e7d76034a942e33/net/quic/core/quic_framer_test.cc
,
Oct 22 2016
Issue 656701 has been merged into this issue.
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272 commit ef8417b1baf6251d9e47fc8b7eb84ffb34e67272 Author: Ryan Hamilton <rch@chromium.org> Date: Thu Oct 20 00:35:50 2016 [m55 merge] Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=jri@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Cr-Commit-Position: refs/heads/master@{#426066} (cherry picked from commit a6fc494d67bf62c40a8fc9eb515bdf27c772d2fb) Review URL: https://codereview.chromium.org/2437913002 . Cr-Commit-Position: refs/branch-heads/2883@{#203} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_flags_list.h [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_framer.cc [modify] https://crrev.com/ef8417b1baf6251d9e47fc8b7eb84ffb34e67272/net/quic/core/quic_framer_test.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cdd00e9c828ed19aff3c6baca623dd7153caee0a commit cdd00e9c828ed19aff3c6baca623dd7153caee0a Author: Ryan Hamilton <rch@chromium.org> Date: Tue Oct 18 22:23:50 2016 [Merge m54] Re-enable the QUIC v33 hacks. protected by FLAGS_quic_remove_v33_hacks2 Effectively, this is rolling back internal change 132908836: Deprecate FLAGS_quic_remove_v33_hacks. BUG= 655846 ,655763 R=jri@chromium.org Review URL: https://codereview.chromium.org/2426823003 . Review URL: https://codereview.chromium.org/2429993002 . Cr-Original-Commit-Position: refs/heads/master@{#426066} Cr-Commit-Position: refs/branch-heads/2840@{#752} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/cdd00e9c828ed19aff3c6baca623dd7153caee0a/net/quic/core/quic_flags.cc
,
Dec 3
hihihihihi |
|||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||
Comment 1 by nsamarak...@gmail.com
, Oct 13 2016