Issue 166593 in chromium: Frequently net::ERR_NETWORK_CHANGED error pages
5,023 views
Skip to first unread message
chro...@googlecode.com
Dec 18, 2012, 2:21:57 AM12/18/12
to chromi...@chromium.org
Status: Untriaged
Owner: ----
CC: sz...@chromium.org
Labels: Type-Bug Pri-2 Area-Internals
New issue 166593 by da...@chromium.org: Frequently net::ERR_NETWORK_CHANGED
error pages
http://code.google.com/p/chromium/issues/detail?id=166593
Frequently net::ERR_NETWORK_CHANGED error pages
The browser is nearly unusable on Windows as nearly every other navigation
fails with net::ERR_NETWORK_CHANGED.
Observed using "25.0.1363.0 (Official Build 173396) canary" on Windows 7.
Owner: ----
CC: sz...@chromium.org
Labels: Type-Bug Pri-2 Area-Internals
New issue 166593 by da...@chromium.org: Frequently net::ERR_NETWORK_CHANGED
error pages
http://code.google.com/p/chromium/issues/detail?id=166593
Frequently net::ERR_NETWORK_CHANGED error pages
The browser is nearly unusable on Windows as nearly every other navigation
fails with net::ERR_NETWORK_CHANGED.
Observed using "25.0.1363.0 (Official Build 173396) canary" on Windows 7.
chro...@googlecode.com
Dec 18, 2012, 2:47:15 AM12/18/12
to chromi...@chromium.org
Updates:
Cc: joaod...@chromium.org
Labels: Internals-Network
Comment #1 on issue 166593 by sz...@chromium.org: Frequently
The CL which introduced ERR_NETWORK_CHANGED should not have caused such
behavior.
As usual,
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
would greatly help. Alternatively, take a look in
chrome://net-internals/#events for events of one of the types:
NETWORK_IP_ADDRESSES_CHANGED
NETWORK_CONNECTIVITY_CHANGED
NETWORK_CHANGED
DNS_CONFIG_CHANGED
so that we know which signal is spurious.
Cc: joaod...@chromium.org
Labels: Internals-Network
Comment #1 on issue 166593 by sz...@chromium.org: Frequently
The CL which introduced ERR_NETWORK_CHANGED should not have caused such
behavior.
As usual,
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
would greatly help. Alternatively, take a look in
chrome://net-internals/#events for events of one of the types:
NETWORK_IP_ADDRESSES_CHANGED
NETWORK_CONNECTIVITY_CHANGED
NETWORK_CHANGED
DNS_CONFIG_CHANGED
so that we know which signal is spurious.
chro...@googlecode.com
Dec 22, 2012, 12:10:16 PM12/22/12
to chromi...@chromium.org
Comment #3 on issue 166593 by da...@chromium.org: Frequently
I'll try to capture a log, but the errors happen randomly and irregularly
enough. Each time it's happened, I've been in the middle of trying to do
something else, and I didn't have the opportunity to capture a log.
By the way, I remember we once had the goal of generating unique error
codes for each error condition. So, you might consider generating
different ERR_*_CHANGED error codes corresponding to each of those events.
chro...@googlecode.com
Jan 28, 2013, 12:55:00 AM1/28/13
to chromi...@chromium.org
Comment #5 on issue 166593 by toxicd...@gmail.com: Frequently
I'm having the same issue. Google Chrome stable (24.0.1312.56) shows a
blank page, while Google Chrome canary (26.0.1395.1) reports
ERR_NETWORK_CHANGED.
Using Windows 8 on a Samsung Series 9 Ultrabook. The problem usually occurs
when awaking from sleep and won't resolve until all the background
processes are killed.
Firefox and Internet Explorer do not have a problem when left open during
sleep.
chro...@googlecode.com
Jan 28, 2013, 7:13:27 AM1/28/13
to chromi...@chromium.org
Comment #6 on issue 166593 by joaod...@chromium.org: Frequently
Managed to reproduce this on Windows 7:
1. serve a 40mb html file from somewhere that reloads itself:
<html><head><script>
document.addEventListener('DOMContentLoaded', function() {
window.location.reload();
});
</script></head><body>
Test
// 40mb of garbage here; e.g. 250K lines of 80 '.' within <!-- -->
</body></html>
2. open chrome://net-internals, open 8 tabs with the 40mb page
3. sleep or disable the network adapter
Usually one of the tabs will get an ERR_NETWORK_CHANGED, the others get
ERR_ABORTED. AFAICT this depends on which stage of the reload the network
change notification comes; if it's during a DNS lookup or while reading the
HTTP headers then an ERR_NETWORK_CHANGED is propagated.
Event 19512 in the attached netlog got that error after following the steps
above.
I'm not sure we want to handle this in any special way; we could treat it
as ERR_ABORTED and just stop loading the page, instead of showing the error
page.
Attachments:
net-internals-log (1).json 703 KB
chro...@googlecode.com
Jan 29, 2013, 3:18:50 AM1/29/13
to chromi...@chromium.org
Comment #9 on issue 166593 by toxicd...@gmail.com: Frequently
I've managed to grab the net internal logs and the output of ipconfig when
this issue was occurring after resuming from sleep. Happened in both stable
and canary. Canary did not have any processes open prior to sleeping,
though it was opened alongside stable.
Google Chrome stable (24.0.1312.56) - blank page
Google Chrome canary (26.0.1395.1) - ERR_NETWORK_CHANGED
Network connection has always been wired.
Attachments:
net-internals-log (canary).json 1.1 MB
net-internals-log (stable).json 836 KB
ipconfig.txt 3.4 KB
chro...@googlecode.com
Jan 29, 2013, 5:10:28 AM1/29/13
to chromi...@chromium.org
Updates:
Cc: pauljen...@chromium.org ero...@chromium.org
Comment #10 on issue 166593 by joaod...@chromium.org: Frequently
The capture from #9 shows NETWORK_IP_ADDRESSES_CHANGED about once per
second, and it keeps killing a spdy_session to www.google.com. That event
is always following by an IPV6_PROBE_JOB logging that ipv6 is supported,
FWIW.
So the underlying problem is the repeated NETWORK_IP_ADDRESSES_CHANGED
notifications; adding some people who may have a clue where these might be
coming from.
Cc: pauljen...@chromium.org ero...@chromium.org
Comment #10 on issue 166593 by joaod...@chromium.org: Frequently
The capture from #9 shows NETWORK_IP_ADDRESSES_CHANGED about once per
second, and it keeps killing a spdy_session to www.google.com. That event
is always following by an IPV6_PROBE_JOB logging that ipv6 is supported,
FWIW.
So the underlying problem is the repeated NETWORK_IP_ADDRESSES_CHANGED
notifications; adding some people who may have a clue where these might be
coming from.
chro...@googlecode.com
Jan 29, 2013, 9:17:39 AM1/29/13
to chromi...@chromium.org
Comment #11 on issue 166593 by pauljen...@chromium.org: Frequently
@toxicdav3: Can you attach the output of several runs of "ipconfig /all"
over the course of several seconds? Even better would be a wireshark log.
chro...@googlecode.com
Feb 10, 2013, 9:56:31 AM2/10/13
to chromi...@chromium.org
Updates:
Cc: jsc...@chromium.org
Comment #13 on issue 166593 by jsc...@chromium.org: Frequently
I hit this pretty reliably when browsing while running a ninja build on my
Windows laptop at home (and infrequently outside of that). I looked at the
log and (if I'm reading it correctly) it matches the chain of events
described in comment #10.
Cc: jsc...@chromium.org
Comment #13 on issue 166593 by jsc...@chromium.org: Frequently
I hit this pretty reliably when browsing while running a ninja build on my
Windows laptop at home (and infrequently outside of that). I looked at the
log and (if I'm reading it correctly) it matches the chain of events
described in comment #10.
chro...@googlecode.com
Feb 11, 2013, 10:58:03 AM2/11/13
to chromi...@chromium.org
Comment #14 on issue 166593 by pauljen...@chromium.org: Frequently
@jschuh: Can you attach a net-internals log, and the output of "ipconfig
/all" before and after some of these NETWORK_IP_ADDRESSES_CHANGED events
pop up in the net-internals log? Even better would be a wireshark log.
chro...@googlecode.com
Feb 25, 2013, 10:51:31 AM2/25/13
to chromi...@chromium.org
Comment #15 on issue 166593 by meta...@gmail.com: Frequently
I've just started getting this problem with Chrome stable, after updating
this morning.
Kubuntu 12.04. Checking the Chrome event log for NETWORK_* events:
31064: NONE
NETWORK_IP_ADDRESSES_CHANGED
Start Time: 2013-02-25 09:33:56.669
t=1361806436669 [st=0] NETWORK_IP_ADDRESSES_CHANGED
31102: NONE
NETWORK_CHANGED
Start Time: 2013-02-25 09:33:58.670
t=1361806438670 [st=0] NETWORK_CHANGED
--> new_connection_type = "CONNECTION_NONE"
31103: NONE
NETWORK_CHANGED
Start Time: 2013-02-25 09:33:58.670
t=1361806438670 [st=0] NETWORK_CHANGED
--> new_connection_type = "CONNECTION_UNKNOWN"
31109: NONE
NETWORK_IP_ADDRESSES_CHANGED
Start Time: 2013-02-25 09:33:58.785
t=1361806438785 [st=0] NETWORK_IP_ADDRESSES_CHANGED
31123: NONE
NETWORK_IP_ADDRESSES_CHANGED
Start Time: 2013-02-25 09:33:58.861
t=1361806438861 [st=0] NETWORK_IP_ADDRESSES_CHANGED
31159: NONE
NETWORK_CHANGED
Start Time: 2013-02-25 09:34:00.861
t=1361806440861 [st=0] NETWORK_CHANGED
--> new_connection_type = "CONNECTION_NONE"
Checking the output of ip addr, both the IPv4 and IPv6 addresses are the
same before and after the error. In case it helps, I have dual active
interfaces, wlan0 and eth0, plus VMware virtual connections to a hosted VM
and an active VPN. I could try reproducing the problem with less of that
stuff active later on today, if you want.
Oh, and the problem happened every time when I attempted to post this
update, so I was forced to switch to Firefox.
Attachments:
net-internals-log.json 7.3 MB
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
chro...@googlecode.com
Feb 25, 2013, 10:53:31 AM2/25/13
to chromi...@chromium.org
Comment #16 on issue 166593 by meta...@gmail.com: Frequently
(So that's Chrome Version 25.0.1364.97, just to be clear.)
chro...@googlecode.com
Feb 25, 2013, 11:11:31 AM2/25/13
to chromi...@chromium.org
Comment #17 on issue 166593 by meta...@gmail.com: Frequently
Downgraded to google-chrome-stable_24.0.1312.70-r181759_amd64.deb from
google-chrome-stable_25.0.1364.97-r183676_amd64.deb, problems seem to have
gone away.
chro...@googlecode.com
Feb 26, 2013, 12:42:42 AM2/26/13
to chromi...@chromium.org
Comment #18 on issue 166593 by sz...@chromium.org: Frequently
The NETWORK_CHANGED events should not really affect the requests quite yet,
but the NETWORK_IP_ADDRESS_CHANGED events do. I wonder what causes so many
signals. Chrome on Linux listens to NEWADDR/DELADDR notifications from
kernel via netlink. I suspect that there are real changes happening to the
non-default interfaces, but Chrome can't distinguish them from the default
route.
If you can reproduce this reliably, could you take a look at the output
of 'dmesg' and see if you see any notices about network interfaces?
chro...@googlecode.com
Apr 15, 2013, 12:26:52 PM4/15/13
to chromi...@chromium.org
Comment #25 on issue 166593 by a...@ilex.fr: Frequently
We have a similar problem on OS X Lion when performing SSL authentication
with French vendor smart cards (CPS -> Carte Professionnelle de Santé).
Here are the details:
Version: 26.0.1410.65 stable
OS: Mac OS X 10.7.5
The steps we perform to reproduce the problem:
0. Use Mac station with direct ethernet connection and card-reader
connected to the machine.
1. Insert vendor smart card in the reader.
2. Start Chrome 26.
3. Point to a test HTTPS page (https://testssl.asipsante.fr).
4. Browser asks to confirm certificate -> we select the certificate.
5. Browser asks to enter card pin code -> we enter the PIN code.
Expect: The data of the current smart card used for authentication is
loaded into the page and displayed.
Observe: The first attempt will result in error 21 ERR_NETWORK_CHANGED.
Subsequent attempts to load the page succeed (by clicking the retry/reload
button on the error page for example).
Other browsers (Safari, Firefox, even Chrome 25) are able to connect to the
test HTTPS site but Chrome 26 won’t connect if authentication process
takes, say, ten seconds to achieve.
chro...@googlecode.com
Apr 16, 2013, 5:47:28 AM4/16/13
to chromi...@chromium.org
Comment #26 on issue 166593 by a...@ilex.fr: Frequently
With reference to my post #25, here are (attached) 2 Chrome logs of this
problem occuring. One file via a proxy, and the other via a direct
connection. The errors (net_error -21) can be seen near the bottom of the
files.
Also, we have found this problem to occur on Mac Lion ONLY, ie. not on
Mountain Lion or Snow Leopard (x32 and x64).
Attachments:
Lion_CPS2ter_TestsslKO_Chrome26_Direct.json 238 KB
Lion_CPS2ter_TestsslKO_Chrome26_Proxy_2.json 275 KB
chro...@googlecode.com
Apr 16, 2013, 3:28:08 PM4/16/13
to chromi...@chromium.org
Updates:
Cc: simo...@chromium.org
Comment #27 on issue 166593 by paulj...@chromium.org: Frequently
I've been trying to figure out where to retry the request. Originally I
thought the right place to retry the requests would be immediately above
the URLRequest layer, similar to the URLFetcher (which already provides
functionality to restart requests upon ERR_NETWORK_CHANGED). For Chrome
main-frame loads this would be in the ResourceDispatcherHostImpl.
simonjam@ pointed out that if received data has already been forwarded onto
Blink (which I think is quite possible) then the restarting would need to
be done in Blink so Blink has a chance to purge the old received data. It
may be the case that many ERR_NETWORK_CHANGED errors occur prior to any
data being forwarded onto Blink but I'm thinking the more complete solution
(have Blink do the retry) is the way to go.
Cc: simo...@chromium.org
Comment #27 on issue 166593 by paulj...@chromium.org: Frequently
I've been trying to figure out where to retry the request. Originally I
thought the right place to retry the requests would be immediately above
the URLRequest layer, similar to the URLFetcher (which already provides
functionality to restart requests upon ERR_NETWORK_CHANGED). For Chrome
main-frame loads this would be in the ResourceDispatcherHostImpl.
simonjam@ pointed out that if received data has already been forwarded onto
Blink (which I think is quite possible) then the restarting would need to
be done in Blink so Blink has a chance to purge the old received data. It
may be the case that many ERR_NETWORK_CHANGED errors occur prior to any
data being forwarded onto Blink but I'm thinking the more complete solution
(have Blink do the retry) is the way to go.
chro...@googlecode.com
Apr 23, 2013, 6:45:30 AM4/23/13
to chromi...@chromium.org
Comment #28 on issue 166593 by da...@tuppeny.com: Frequently
I've been seeing this error quite a lot lately too; latest stable Chrome on
Windows 8 64bit. Mostly happens at home on a machine that is WiFi, but a
colleague also just had it here at work on Windows 7 64bit with no WiFi.
chro...@googlecode.com
Apr 23, 2013, 7:26:09 AM4/23/13
to chromi...@chromium.org
Updates:
Labels: -Needs-Feedback M-29
Comment #29 on issue 166593 by s...@chromium.org: Frequently
Adjusting labels, since it looks we have enough feedback and an idea of
what to do . Also adding a tentative M-29 label.
Labels: -Needs-Feedback M-29
Comment #29 on issue 166593 by s...@chromium.org: Frequently
Adjusting labels, since it looks we have enough feedback and an idea of
what to do . Also adding a tentative M-29 label.
chro...@googlecode.com
May 1, 2013, 3:46:01 AM5/1/13
to chromi...@chromium.org
Comment #31 on issue 166593 by welc...@gmail.com: Frequently
I have this issue on my brand new Samsung Chomebook.
chro...@googlecode.com
May 1, 2013, 3:47:01 AM5/1/13
to chromi...@chromium.org
Comment #32 on issue 166593 by welc...@gmail.com: Frequently
I have this issue on my brand new Samsung Chromebook.
chro...@googlecode.com
May 1, 2013, 2:42:18 PM5/1/13
to chromi...@chromium.org
Comment #33 on issue 166593 by bazc...@gmail.com: Frequently
This is driving me nuts, seems to only happen for me on https pages.
Only thing I recall changing was adding a vpn for a couple of days and then
removing it. Seemed to happen after that.
chro...@googlecode.com
May 2, 2013, 11:21:05 AM5/2/13
to chromi...@chromium.org
Comment #35 on issue 166593 by paulj...@chromium.org: Frequently
Matt: Are you sure we never return ERR_NETWORK_CHANGED on requests that
have received any data? HostResolverImpl aborts requests with
ERR_NETWORK_CHANGED when an IP address change happens. I don't think any
data has been received if we haven't finished DNS. However,
SpdySessionPool calls CloseCurrentSessions(ERR_NETWORK_CHANGED) in a number
of situations including an IP address change, and it looks like it closes |
active_streams_| with ERR_NETWORK_CHANGED. It does look like the other
pools only call FlushWithError() which sounds like it doesn't close active
sockets.
chro...@googlecode.com
May 2, 2013, 12:05:13 PM5/2/13
to chromi...@chromium.org
Comment #36 on issue 166593 by mme...@chromium.org: Frequently
I can't say anything about SPDY. I'm pretty sure (Though not 100%
confident) that we don't for the more common HTTP/HTTPS cases.
chro...@googlecode.com
May 2, 2013, 12:25:16 PM5/2/13
to chromi...@chromium.org
Updates:
Cc: aka...@chromium.org
Comment #37 on issue 166593 by paulj...@chromium.org: Frequently
Fred, SpdySessionPool calls CloseCurrentSessions(ERR_NETWORK_CHANGED) in a
number of situations including an IP address change. Will this close SPDY
connections, with ERR_NETWORK_CHANGED, that have already received some data?
Cc: aka...@chromium.org
Comment #37 on issue 166593 by paulj...@chromium.org: Frequently
Fred, SpdySessionPool calls CloseCurrentSessions(ERR_NETWORK_CHANGED) in a
number of situations including an IP address change. Will this close SPDY
connections, with ERR_NETWORK_CHANGED, that have already received some data?
chro...@googlecode.com
May 2, 2013, 1:37:22 PM5/2/13
to chromi...@chromium.org
Comment #38 on issue 166593 by will...@chromium.org: Frequently
Yes. It's quite possible we should only remove the sessions from the pool
and allow existing sessions to continue to make progress, perhaps using a
PING to time out the sessions.
chro...@googlecode.com
May 12, 2013, 7:29:39 AM5/12/13
to chromi...@chromium.org
Comment #39 on issue 166593 by legendm...@gmail.com: Frequently
I can reproduce this on 27.0.1453.81 (Official Build 198567) beta-m
chro...@googlecode.com
May 22, 2013, 2:36:51 PM5/22/13
to chromi...@chromium.org
Comment #40 on issue 166593 by starrych...@oliveyou.net: Frequently
My impression is it seems for frequent when the computer goes to sleep and
wakes up.
chro...@googlecode.com
May 23, 2013, 2:27:46 AM5/23/13
to chromi...@chromium.org
Updates:
Labels: -Pri-2 Pri-1
Comment #41 on issue 166593 by da...@chromium.org: Frequently
I'm seeing this quite frequently on 29.0.1514.1 (Official Build 201432)
canary, running under Win7. I think this should be considered a P1 bug as
it makes Chrome unusable.
Maybe this is related to going on / off VPN, but I would only expect to see
this error intermittently during VPN transition. Instead, I see it minutes
after the VPN state has changed. Perhaps we only detect socket failures at
that time.
It is safe to open a new connection to send a request if we feel confident
that the request was not already sent. We are probably missing an
opportunity to detect that a reused connection is invalid and failover to
creating a new connection, etc.
Labels: -Pri-2 Pri-1
Comment #41 on issue 166593 by da...@chromium.org: Frequently
I'm seeing this quite frequently on 29.0.1514.1 (Official Build 201432)
canary, running under Win7. I think this should be considered a P1 bug as
it makes Chrome unusable.
Maybe this is related to going on / off VPN, but I would only expect to see
this error intermittently during VPN transition. Instead, I see it minutes
after the VPN state has changed. Perhaps we only detect socket failures at
that time.
It is safe to open a new connection to send a request if we feel confident
that the request was not already sent. We are probably missing an
opportunity to detect that a reused connection is invalid and failover to
creating a new connection, etc.
chro...@googlecode.com
May 23, 2013, 2:44:47 AM5/23/13
to chromi...@chromium.org
Comment #42 on issue 166593 by da...@chromium.org: Frequently
Note: The rules for knowing when it is safe to automatically retry a HTTP
request is quite subtle. See HttpNetworkTransaction::ShouldResendRequest
and its callers. It seems like perhaps a network change detected at the
SPDY level is not being properly propagated to this level. Perhaps we just
need to generate the right error code, or perhaps this code needs to learn
about a new error code. I believe this kind of restarting is best done at
the HttpNetworkTransaction layer. The HttpCacheTransaction shouldn't have
to be aware that any retrying is happening, for instance.
chro...@googlecode.com
May 23, 2013, 10:34:25 AM5/23/13
to chromi...@chromium.org
Comment #43 on issue 166593 by mme...@chromium.org: Frequently
Willchan is actually of the opposite opinion - that this should not be done
automatically be the network stack, but rather by the embedder.
chro...@googlecode.com
May 23, 2013, 10:24:59 PM5/23/13
to chromi...@chromium.org
Comment #44 on issue 166593 by paulj...@chromium.org: Frequently
Here is my first attempt at a fix: http://crrev.com/14314013
I retried using the NavigationController. Upon further discussion with
Darin I came up with my second attempt which I think is aligned with what
Darin just mentioned about restarting at the HttpNetworkTransaction layer.
Here is my second attempt at a fix: http://crrev.com/15001007
As Matt mentioned, Will didn't necessarily agree with this approach.
Matt and I discussed more and thought maybe a ChromeNetworkDelegate
solution was a possible middle-ground. Modifying RDHI to do the restarting
seemed like it would be making a very complicated component even more
complicated. My first and second attempts were very small.
I'm in the middle of an 11 day vacation, but would greatly appreciate if
Darin and Will could reach an agreement on an acceptable solution.
I think the current contention points are:
1) Can we rely on the idempotency of HTTP GET requests?
2) Where should the restarting be done? (NavigationController, RDHI,
ChromeNetworkDelegate or HttpNetworkTransaction)
Darin, I'm intrigued by this ERR_NETWORK_CHANGED error code appearing
minutes after the VPN state has changed. Comparing the output of "ipconfig
/all" before and after the ERR_NETWORK_CHANGED error code appears might
provide useful insight. A net-internals log is always good too.
chro...@googlecode.com
May 24, 2013, 10:44:14 AM5/24/13
to chromi...@chromium.org
Comment #45 on issue 166593 by da...@tuppeny.com: Frequently
There update to Chrome today on the stable channel that may have made this
problem significantly worse :/
I have 4 default tabs that open in Chrome; the first one is Google.co.uk.
Before today, I rarely saw this issue at work (maybe every few weeks); but
today I've had the first tab (Google) show this message quite a lot (more
than 5 times).
chro...@googlecode.com
May 24, 2013, 11:05:08 AM5/24/13
to chromi...@chromium.org
Comment #46 on issue 166593 by mme...@chromium.org: Frequently
Danny: If your corporate policy permits, an about:net-internals log of
this happening would be great. See
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
for details. Cookies won't be included in the log, but URLs (including
query strings), Chrome's DNS cache, and a few network configuration details
will be included. You can also email the log to Paul and I directly
instead of posting it here, where it will be publicly available.
The results of following Paul's instructions on running "ipconfig /all"
could also be illuminating.
chro...@googlecode.com
May 24, 2013, 11:08:08 AM5/24/13
to chromi...@chromium.org
Comment #47 on issue 166593 by mme...@chromium.org: Frequently
danny: What platform are you on? I was assuming you were on Windows...
chro...@googlecode.com
Jun 3, 2013, 10:57:08 PM6/3/13
to chromi...@chromium.org
Comment #49 on issue 166593 by ahow...@howdencompany.com: Frequently
Getting this error when using a tethered iPhone connection.
Actual IP does change periodically.
9462: NONE
NETWORK_IP_ADDRESSES_CHANGED
Start Time: 2013-06-04 11:34:45.983
t=1370309685983 [st=0] NETWORK_IP_ADDRESSES_CHANGED
9463: IPV6_PROBE_JOB
IPv6 Not Supported
Start Time: 2013-06-04 11:34:45.983
t=1370309685983 [st=0] IPV6_PROBE_RUNNING [dt=39]
--> ipv6_support_status = "Global ipv6 address
missing"
--> ipv6_supported = false
9464: PROXY_SCRIPT_DECIDER
Start Time: 2013-06-04 11:34:45.984
t=1370309685984 [st= 0] +PROXY_SCRIPT_DECIDER [dt=110]
t=1370309685984 [st= 0] +PROXY_SCRIPT_DECIDER_WAIT [dt=110]
t=1370309686094 [st=110] CANCELLED
t=1370309686094 [st=110] -PROXY_SCRIPT_DECIDER
9465: PROXY_SCRIPT_DECIDER
Start Time: 2013-06-04 11:34:45.984
t=1370309685984 [st= 0] +PROXY_SCRIPT_DECIDER [dt=110]
t=1370309685985 [st= 1] +PROXY_SCRIPT_DECIDER_WAIT [dt=109]
t=1370309686094 [st=110] CANCELLED
t=1370309686094 [st=110] -PROXY_SCRIPT_DECIDER
9469: NONE
DNS_CONFIG_CHANGED
Start Time: 2013-06-04 11:34:46.094
t=1370309686094 [st=0] DNS_CONFIG_CHANGED
--> append_to_multi_label_name = false
--> attempts = 2
--> edns0 = false
--> nameservers =
["198.142.0.51:53","61.88.88.88:53"]
--> ndots = 1
--> num_hosts = 51
--> rotate = false
--> search = []
--> timeout = 1
9472: NONE
NETWORK_CONNECTIVITY_CHANGED
Start Time: 2013-06-04 11:34:46.990
t=1370309686990 [st=0] NETWORK_CONNECTIVITY_CHANGED
--> new_connection_type = "CONNECTION_UNKNOWN"
chro...@googlecode.com
Jun 25, 2013, 9:27:51 AM6/25/13
to chromi...@chromium.org
Comment #51 on issue 166593 by florami...@gmail.com: Frequently
Chrome useless on MackBook Pro because of these errors
chro...@googlecode.com
Jun 25, 2013, 9:30:32 AM6/25/13
to chromi...@chromium.org
Comment #52 on issue 166593 by joaod...@chromium.org: Frequently
#51 can you give more details? What is the Chrome version? What is the
network type? Do you have more than one network connection? Do you use a
VPN?
If you get this error very frequently then can you post a network capture?
(see
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
for details)
chro...@googlecode.com
Jun 29, 2013, 1:32:50 PM6/29/13
to chromi...@chromium.org
Comment #53 on issue 166593 by luke.orb...@gmail.com: Frequently
I`m having the same issue here for about a week, maybe every 10th page
request is aborted with ERR_NETWORK_CHANGED (e.g. the first attempt to post
this, typing this text for the second time now...).
- Chrome 27.0.1453.116 m, Windows 8 64bit
- One active network connection (wifi adapter from TP-LINK), there are
another two virtual network adapters (VMWare), which are disabled
- static ip, no VPN, definitively no network changes, max signal strength
(only 5 meters away from the wifi router)
- no problems with other browsers
- none of the popular fixes ("turn off automatic network detection", which
wasn`t even enabled on this machine) helped :(
Attachments:
net-internals-log.json 108 KB
chro...@googlecode.com
Jun 30, 2013, 9:38:53 PM6/30/13
to chromi...@chromium.org
Comment #54 on issue 166593 by paulj...@chromium.org: Frequently
@luke.orbit123: Looks like Windows is claiming occasional IP address
changes. Could you post the output of "ipconfig /all" before and after
encountering ERR_NETWORK_CHANGED.
chro...@googlecode.com
Jul 3, 2013, 5:27:24 PM7/3/13
to chromi...@chromium.org
Comment #58 on issue 166593 by paulj...@chromium.org: Frequently
DHCP lease renewals do not trigger IP address change notifications, at
least from my testing on a Win7 laptop. I suspect luke.orbit123 is
encountering something else.
chro...@googlecode.com
Jul 15, 2013, 9:47:20 AM7/15/13
to chromi...@chromium.org
Comment #60 on issue 166593 by owenblac...@gmail.com: Frequently
Just a note to mention that I'm still seeing this on my phone, with the new
build of Chrome that was pushed to it over the last few days.
The About screen tells me:
Application version Chrome 28.0.1500.64
OS Android 4.2.2; Nexus 4 Build/JDQ39
WebKit version 537.36 (@153022)
JavaScript version V8 3.18.5.9
A screenshot is attached (if you can ignore the Facebook Chat Heads bubble
on the right-hand side ;o)
Attachments:
ERR_NETWORK_CHANGED screenshot 2013-07-15.png 116 KB
chro...@googlecode.com
Jul 27, 2013, 4:46:38 AM7/27/13
to chromi...@chromium.org
Comment #62 on issue 166593 by olszak.k...@gmail.com: Frequently
When I'm disable global privacy ipv6 on operating system, chromium was
working correct.
chro...@googlecode.com
Jul 31, 2013, 1:33:18 PM7/31/13
to chromi...@chromium.org
Comment #65 on issue 166593 by paulj...@chromium.org: Frequently
@szym: Aren't IPv6 privacy addresses always different (so as to maintain
privacy) and hence never renewed?
chro...@googlecode.com
Jul 31, 2013, 1:36:18 PM7/31/13
to chromi...@chromium.org
Comment #66 on issue 166593 by sz...@chromium.org: Frequently
They are, and they will be an issue, but in #61, the address is supposedly
unchanged.
chro...@googlecode.com
Sep 23, 2013, 11:35:05 PM9/23/13
to chromi...@chromium.org
Comment #67 on issue 166593 by pma...@google.com: Frequently
I started seeing this bug on my Gentoo machine, just after I updated my
router
to the latest OpenWRT trunk. By default, it sends out an IPv6 ULA prefix,
but uses a preferred lifetime of 0 if native connectivity is available.
Client information:
- Vanilla kernel 3.11.0
- Chromium 30.0.1599.37 (222353)
"ip monitor" and "radvdump" repeat the following information every few
seconds. Note that the ULA address appears for an instant, and then
immediately
changes to deprecated:
$ ip monitor
2: enp0s25 inet6 2601:9:3400:4c0:222:4dff:fea7:c226/64 scope global
dynamic
valid_lft 1765sec preferred_lft 1759sec
prefix 2601:9:3400:4c0::/64 dev enp0s25 onlink autoconf valid 1759
preferred 1759
2: enp0s25 inet6 fd62:6c2b:203c:0:222:4dff:fea7:c226/64 scope global
dynamic
valid_lft 7200sec preferred_lft 0sec
2: enp0s25 inet6 fd62:6c2b:203c:0:222:4dff:fea7:c226/64 scope global
deprecated dynamic
valid_lft 7200sec preferred_lft 0sec
prefix fd62:6c2b:203c::/64 dev enp0s25 onlink autoconf valid 7200 preferred
0
Unknown message: 0000004c 00000044 00000000
Unknown message: 00000044 00000044 00000000
$ sudo radvdump
#
# radvd configuration generated by radvdump 1.9.3
# based on Router Advertisement from fe80::2cb0:5dff:fe9c:38c3
# received by interface enp0s25
#
interface enp0s25
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 0;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
AdvLinkMTU 1500;
prefix 2601:9:3400:4c0::/64
{
AdvValidLifetime 1708;
AdvPreferredLifetime 1708;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix fd62:6c2b:203c::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 0;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
route 2601:9:3400:4c0::/60
{
AdvRoutePreference medium;
AdvRouteLifetime 1708;
}; # End of route definition
route fd62:6c2b:203c::/48
{
AdvRoutePreference medium;
AdvRouteLifetime 7200;
}; # End of route definition
RDNSS fd62:6c2b:203c::1
{
AdvRDNSSLifetime 1800;
}; # End of RDNSS definition
DNSSL lan
{
AdvDNSSLLifetime 1800;
}; # End of DNSSL definition
}; # End of interface definition
I can hack around the problem by commenting out this line in my
router's /etc/config/network:
config globals 'globals'
#option ula_prefix 'fd62:6c2b:203c::/48'
It still sends an RA every few seconds, but without the ULA section.
"ip monitor" now only repeats this, and Chrome stops complaining:
$ ip monitor
prefix 2601:9:3400:4c0::/64 dev enp0s25 onlink autoconf valid 3199
preferred 1800
Unknown message: 0000004c 00000044 00000000
Unknown message: 00000044 00000044 00000000
I'm not sure if the bug is more with the kernel sending spurious address
changes, or Chrome's reaction to them.
chro...@googlecode.com
Sep 26, 2013, 10:33:40 AM9/26/13
to chromi...@chromium.org
Comment #68 on issue 166593 by paulj...@chromium.org: Frequently
@pmarks: I'm intrigued by the "preferred_lft 0sec" messages. Seems the
address is deprecated the instant it's sent out. Could you wireshark the
router advertisements so we can see if what the router is sending out
matches what the kernel is sending out?
chro...@googlecode.com
Sep 26, 2013, 4:03:06 PM9/26/13
to chromi...@chromium.org
Comment #69 on issue 166593 by pma...@google.com: Frequently
pauljensen: yes, that's what the router is actually sending; see my
radvdump output:
AdvPreferredLifetime 0;
This behavior is basically consistent with RFC6204:
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero ...
So even if you take ULAs out of the picture, a standards-complaint router
will advertise preferred_lft 0 for a while if your ISP does a prefix change.
In Linux net/ipv6/addrconf.c, this is the line that causes the deprecated
flag to be disappear briefly:
ifp->flags &= ~IFA_F_DEPRECATED;
It might make sense to change that, but Chrome would still behave poorly
until everyone upgrades their kernel.
chro...@googlecode.com
Dec 12, 2013, 11:56:04 AM12/12/13
to chromi...@chromium.org
Comment #72 on issue 166593 by hugomart...@gmail.com: Frequently
I'm seeing this issue frequently with Chrome too.
Error code: ERR_NETWORK_CHANGED
chro...@googlecode.com
Dec 16, 2013, 4:42:54 AM12/16/13
to chromi...@chromium.org
Comment #73 on issue 166593 by joaod...@chromium.org: Frequently
I got this error repeatedly today on a mac. I was connected via Wifi, and
the Ethernet port wasn't being used because the network requires an
authentication certificate that was missing.
So while I could browse via Wifi, the Ethernet port kept trying to connect
to the network, failing, and falling back on an auto-configured IPv6
address. This happened every 5 to 10 seconds, and triggered
NETWORK_IP_ADDRESSES_CHANGED each time, which led to the
ERR_NETWORK_CHANGED for any pending navigations at that moment. The problem
went away after getting the certificate and fixing the Ethernet connection.
I wonder if dropping connections on ERR_NETWORK_CHANGED is the right thing
to do. One NIC may be working fine while another is flaking for whatever
reason, so why drop the connections that are going through the first? If
connectivity really breaks completely then another error will eventually
surface (e.g. no route, EPIPE, etc)
chro...@googlecode.com
Dec 16, 2013, 12:08:58 PM12/16/13
to chromi...@chromium.org
Updates:
Blockedon: chromium:268042
Comment #74 on issue 166593 by paulj...@chromium.org: Frequently
@pmarks: Let's move this discussion to Issue 268042 now that we've
identified a specific cause and possible solution.
@joaodasilva: We don't drop normal TCP connections on ERR_NETWORK_CHANGED.
We abort connect jobs, close idle connections and drop SPDY connections I
believe. I think you are right that if connectivity is actually broken TCP
connections would receive an error signal on linux, but I think that is O/S
specific, and I've heard that on Windows that is not the case, hence the
need for the NetworkChangeNotifier. The choice to use the
NetworkChangeNotifier's signals on non-Windows O/S's I think is one that
provides better cross-platform uniformity, but is something we could
reconsider.
Blockedon: chromium:268042
Comment #74 on issue 166593 by paulj...@chromium.org: Frequently
@pmarks: Let's move this discussion to Issue 268042 now that we've
identified a specific cause and possible solution.
@joaodasilva: We don't drop normal TCP connections on ERR_NETWORK_CHANGED.
We abort connect jobs, close idle connections and drop SPDY connections I
believe. I think you are right that if connectivity is actually broken TCP
connections would receive an error signal on linux, but I think that is O/S
specific, and I've heard that on Windows that is not the case, hence the
need for the NetworkChangeNotifier. The choice to use the
NetworkChangeNotifier's signals on non-Windows O/S's I think is one that
provides better cross-platform uniformity, but is something we could
reconsider.
chro...@googlecode.com
Dec 16, 2013, 12:49:05 PM12/16/13
to chromi...@chromium.org
Comment #77 on issue 166593 by pma...@google.com: Frequently
> I think you are right that if connectivity is actually broken TCP
> connections would receive an error signal on linux
I'm not sure that's accurate. Android has a tcp_nuke_addr() function
> connections would receive an error signal on linux
that's called when an interface goes down, but it's not in the mainline
kernel:
https://android.googlesource.com/kernel/common/+/2c3c5fafd215820e756676e9f46e8eb9c904338b%5E!/
chro...@googlecode.com
Dec 16, 2013, 1:07:10 PM12/16/13
to chromi...@chromium.org
Comment #78 on issue 166593 by joaod...@chromium.org: Frequently
It's unfortunate that machines with misconfigured IPv6 setups repeatedly
generate this notification. It may also be a common scenario on mobile
devices with flaky wireless nics.
Looks like tcp_nuke_addr() drops all sockets but only for the interface
that went down. ERR_NETWORK_CHANGED drops all pending connections though.
That may be correct, if the network change means that pending connections
will get a name resolved differently, or a different route.
Maybe ERR_NETWORK_CHANGED is too coarse? Connect jobs could be
automatically retried when the network changes, and idle connections could
be dropped only if the address that they're using is gone. I don't
understand why SPDY connections are dropped on this notification.
Just my $0.02, I'm not familiar with the networking code. I just wonder if
the user experience could be improved in these cases.
chro...@googlecode.com
Dec 16, 2013, 1:12:10 PM12/16/13
to chromi...@chromium.org
Comment #79 on issue 166593 by mme...@chromium.org: Frequently
Dead SPDY connections make for a horrible user experience. If you have a
dead HTTP connection, reloading the page will make a new socket, and all
will be well (The old socket will generally be closed when the old request
is cancelled, or soon afterward).
With SPDY, however, reloading a hung page will reuse the SPDY session until
the socket is killed with some network error.
chro...@googlecode.com
Dec 16, 2013, 1:27:12 PM12/16/13
to chromi...@chromium.org
Comment #80 on issue 166593 by joaod...@chromium.org: Frequently
Thanks, that's good to know. Is it possible to determine the address used
by each SPDY connection, and drop the connection only if that address is
gone or was modified since the connection started?
Or would it make sense to trigger a keep-alive message and start a timeout?
chro...@googlecode.com
Dec 16, 2013, 1:42:12 PM12/16/13
to chromi...@chromium.org
Comment #83 on issue 166593 by mme...@chromium.org: Frequently
We don't get that info on Windows, however. No idea about OSX or iOS.
chro...@googlecode.com
Dec 24, 2013, 11:28:56 PM12/24/13
to chromi...@chromium.org
Comment #84 on issue 166593 by da...@chromium.org: Frequently
FYI, this bug is still plaguing me on my Windows 7 laptop (which I rarely
use). It is running "34.0.1759.0 (Official Build 242366) canary" and
experiencing this bug frequently.
chro...@googlecode.com
Dec 25, 2013, 6:50:27 PM12/25/13
to chromi...@chromium.org
Comment #85 on issue 166593 by nmoli...@gmail.com: Frequently
I've also had this same issue, in Windows 8.1.
chro...@googlecode.com
Dec 31, 2013, 9:07:17 PM12/31/13
to chromi...@chromium.org
Comment #86 on issue 166593 by jcalla...@pylusd.org: Frequently
First time post...both my XP and Windows 8 laptops are now experiencing
ERR_CACHE_MISS and ERR_NETWORK_CHANGED. Started out infrequent, now about
every 3rd page on both. Any ideas on how to fix.....that is ideas which a
novice can understand? thx
chro...@googlecode.com
Jan 2, 2014, 10:12:35 AM1/2/14
to chromi...@chromium.org
Comment #87 on issue 166593 by paulj...@chromium.org: Frequently
@jcallahan: The ERR_NETWORK_CHANGED come from Windows and Chrome thinking
some networking configuration has changed spuriously. If you could
simultaneously collect a wireshark and net-internals log covering a time
when you receive an ERR_NETWORK_CHANGED error I could help diagnose. Here
are directions for collecting a net-internals log:
http://dev.chromium.org/for-testers/providing-network-details
chro...@googlecode.com
Jan 2, 2014, 10:17:24 AM1/2/14
to chromi...@chromium.org
Comment #88 on issue 166593 by owenblac...@gmail.com: Frequently
@pauljensen: It's not just Windows and Chrome; it's a problem I see *a lot*
on my Android (on Nexus 4). And yeah, of course the network might have
changed there; it's a *mobile* device ;o)
chro...@googlecode.com
Jan 20, 2014, 11:33:04 PM1/20/14
to chromi...@chromium.org
Comment #90 on issue 166593 by ivuc...@gmail.com: Frequently
I have not been using Chrome for months on Windows now due to this issue.
This happens on both Chrome and Canary.
Chrome repeatedly thinks the IP address changed when it didn't. Chrome also
seems intent on using nonexistent IPv6 connection (there is no
non-linklocal IPv6 address, and I have disabled IPv6 on any adapter that is
in connected status).
Errors are as described by others (NETWORK_CHANGED,
NETWORK_CONNECTIVITY_CHANGED, NETWORK_IP_ADDRESSES_CHANGED etc). All errors
are without further details; there is talk about IP addresses having
changed, but without further explanation.
Completely disabling network adapters apart from WiFi helped. So obviously
one of the adapter had faulty settings -- but nothing visible through UI.
I have pinpointed the issue to the
otherwise-disconnected-and-not-used-in-months Ethernet network adapter. If
I disable this adapter, issue goes away; if I enable it, issue appears.
The only significant 'playful' thing I've done with networking is that I
have played with routing IPv6 on Windows a few months ago, but never was
the ethernet port involved. The machine connected through OpenVPN to an
IPv6 enabled system, and then tried to route the data to other machines on
virtual WiFi. Again, the ethernet adapter that I have to disable here was
NOT involved in the IPv6 experiment, and toggling the IPv6 support has no
effect on whether the issue appears.
chro...@googlecode.com
Feb 6, 2014, 6:07:26 AM2/6/14
to chromi...@chromium.org
Comment #91 on issue 166593 by bugdro...@chromium.org: Frequently
net::ERR_NETWORK_CHANGED error pages
http://code.google.com/p/chromium/issues/detail?id=166593#c91
------------------------------------------------------------------------
r249349 | paulj...@chromium.org | 2014-02-06T11:02:58.188336Z
Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_pool.cc?r1=249349&r2=249348&pathrev=249349
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_unittest.cc?r1=249349&r2=249348&pathrev=249349
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.cc?r1=249349&r2=249348&pathrev=249349
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.h?r1=249349&r2=249348&pathrev=249349
Deprecate instead of close SPDY sessions upon network change. This brings
our SPDY behavior for network changes more in line with our HTTP behavior
where we only close idle sockets. The benefit of this is fewer SPDY streams
interrupted with ERR_NETWORK_CHANGED while still maintaining the basic
principle that after a network change new requests get routed properly to
possibly newly available hosts (http://crbug.com/26156). For now this
change only affects Android, Windows and iOS as these OSs appear to close
TCP connections upon network disconnects. I'm avoiding applying this
change to other OSs because it would lead to more sockets silently dying
and waiting indefinitely rather than quickly failing upon network
disconnects.
BUG=166593
Review URL: https://codereview.chromium.org/129873010
------------------------------------------------------------------------
chro...@googlecode.com
Feb 19, 2014, 5:23:30 PM2/19/14
to chromi...@chromium.org
Comment #92 on issue 166593 by m.schust...@googlemail.com: Frequently
On my (dead slow, so no way of generating a Wireshark trace) netbook
running fully patched W7 x64 and Chrome "32.0.1700.107 (Offizieller Build
248368) m"
I also experience this problem and was able to catch two DNS_CONFIG_CHANGED
events:
742768: NONE
DNS_CONFIG_CHANGED
Start Time: 2014-02-19 23:14:30.016
t=1392848070016 [st=0] DNS_CONFIG_CHANGED
--> append_to_multi_label_name = true
--> attempts = 2
--> edns0 = false
--> nameservers = []
--> ndots = 1
--> num_hosts = 0
--> rotate = false
--> search = []
--> timeout = 1
--> unhandled_options = false
--> use_local_ipv6 = false
742769: NONE
DNS_CONFIG_CHANGED
Start Time: 2014-02-19 23:14:30.041
t=1392848070041 [st=0] DNS_CONFIG_CHANGED
--> append_to_multi_label_name = false
--> attempts = 2
--> edns0 = false
--> nameservers =
["[2001:67c:194::5253]:53","195.234.128.7:53","195.234.128.16:53"]
--> ndots = 1
--> num_hosts = 70
--> rotate = false
--> search = ["cm.cablesurf.de"]
--> timeout = 1
--> unhandled_options = false
--> use_local_ipv6 = false
The router is attached via WLAN and is a Technicolor 7200 cable modem.
ipconfig shows strange stuff going on in IPv6:
Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:
Verbindungsspezifisches DNS-Suffix: cm.cablesurf.de
IPv6-Adresse. . . . . . . . . . . :
2001:4c50:15f:fa00:4daf:48a7:3974:223b
IPv6-Adresse. . . . . . . . . . . :
2001:4c50:15f:fa00:9200:4eff:fe66:1e35
Temporäre IPv6-Adresse. . . . . . :
2001:4c50:15f:fa00:b83e:cfc9:c0a9:3f5a
Verbindungslokale IPv6-Adresse . : fe80::4daf:48a7:3974:223b%11
IPv4-Adresse . . . . . . . . . . : 192.168.0.11
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : fe80::4632:c8ff:feb0:ace2%11
192.168.0.1
Is it possible that my CM sends out strange IPv6 Router Advertisements
causing Windoze to believe it has a new IP address?!
chro...@googlecode.com
Feb 20, 2014, 12:18:27 PM2/20/14
to chromi...@chromium.org
Comment #93 on issue 166593 by mme...@chromium.org: Frequently
The first DNS_CONFIG_CHANGED event shows that we can't get a valid DNS
config, briefly, before getting a valid on 25 milliseconds later. So
something is really changing on your system's DNS config to some other
(invalid, apparently) state. We pick up on that, and then it changes it
back to what it was.
chro...@googlecode.com
Feb 27, 2014, 10:18:02 PM2/27/14
to chromi...@chromium.org
Comment #94 on issue 166593 by christia...@gmail.com: Frequently
Maybe a clue: I've had the problem for a long time, and based on comment
#90 I tried disabling the VirtualBox network adapter. Seems to have solved
the issue. Obviously it's more a workaround than a fix, but I hope this
information helps.
chro...@googlecode.com
Mar 12, 2014, 5:57:54 PM3/12/14
to chromi...@chromium.org
Comment #101 on issue 166593 by mme...@chromium.org: Frequently
We do use TCP keepalives with 45 second timeouts on non-mobile (They're
disable on mobile due to battery drain). Of course...once we send a ping,
we still have to wait for the timeout, too.
I'm not sure if effectively dead sockets will still try to send keepalives
or not. WE could be more aggressive that 45 seconds, but we keep a lot of
idle sockets around, and it seems like that would soon get excessive.
chro...@googlecode.com
Apr 4, 2014, 7:23:53 AM4/4/14
to chromi...@chromium.org
Comment #104 on issue 166593 by trytop...@gmail.com: Frequently
I also have the same problem after updating my wifi adpater driver.
chro...@googlecode.com
May 23, 2014, 6:04:06 AM5/23/14
to chromi...@chromium.org
Comment #106 on issue 166593 by postadel...@gmail.com: Frequently
Same issue on chromium Version 34.0.1847.116
chro...@googlecode.com
Mar 31, 2015, 1:03:37 PM3/31/15
to chromi...@chromium.org
Comment #110 on issue 166593 by mme...@chromium.org: Frequently
net::ERR_NETWORK_CHANGED error pages
https://code.google.com/p/chromium/issues/detail?id=166593
On real network changes, existing DNS requests and connections tend to be
blackholed. When there's a network change of some sort, we often can't be
completely sure exactly what actually changed (Or at least we can't be sure
on all platforms).
chro...@googlecode.com
Mar 31, 2015, 1:05:36 PM3/31/15
to chromi...@chromium.org
Updates:
Labels: -Cr-Internals-Network Cr-Internals-Network-Connectivity
Comment #111 on issue 166593 by mme...@chromium.org: Frequently
(No comment was entered for this change.)
Labels: -Cr-Internals-Network Cr-Internals-Network-Connectivity
Comment #111 on issue 166593 by mme...@chromium.org: Frequently
(No comment was entered for this change.)
chro...@googlecode.com
Mar 31, 2015, 3:04:52 PM3/31/15
to chromi...@chromium.org
Comment #114 on issue 166593 by ero...@chromium.org: Frequently
I agree that this is a problem, and should be fixed.
ERR_NETWORK_CHANGED is used in several places now: aborting DNS requests,
ssl configuration changed, socket pool is flushed, so I am not sure exactly
which flavor this bug is about. But really none of these should be
surfacing a user-facing error of ERR_NETWORK_CHANGED.
As I recall from the history, the original reason for adding this error was
to kill open sockets on network change. This was done to try and fix a
nebulous problem being reported for a user on Mac OS X, where they wound up
with stuck sockets seeming to correspond with network transitions. Moreover
if memory serves it was not reproduced locally, but the problem was only
inferred from logs.
Arguably this is a bug in the host network stack, and Chrome is hacking
around it by killing connections, which is somewhat heavy weight and can
result in a bad user experience (as this bug indicates).
I think there are some alternate solutions to this problem. What we are
doing today may only be helping a minority of users and hurting the rest.
My perspective is that:
* DNS requests should NEVER be failed with ERR_NETWORK_CHANGED
* Sockets should NEVER be failed with ERR_NETWORK_CHANGED
If we have evidence that DNS resolution attempts and TCP sockets are still
getting stuck following network transitions, then we can do something more
reactive that doesn't always murder outstanding networking:
On network transition, consider all outstanding TCP sockets as being
potentially hung. To address this set a timer to timeout any socket that
does not receive data within the next XX seconds. If this actually does
happen, the socket can be failed with a timeout error (maybe
ERR_TIMED_OUT_FOLLOWING_NETWORK_CHANGE) which addresses the original user
case of having sockets in a perpetually hung state. In the case of DNS
requests, there is already built in retry logic for the HostResolverImpl,
so without doing anything I believe the requests will time out on their own
accord and be re-tried. We should never be surfing ERR_NETWORK_CHANGED for
DNS requests as they can transparently be retried if necessary, and failing
them for this spurious error is just annoying.
What do you think?
chro...@googlecode.com
Mar 31, 2015, 3:18:52 PM3/31/15
to chromi...@chromium.org
Comment #117 on issue 166593 by mme...@chromium.org: Frequently
I'd certainly be fine with reviving
https://codereview.chromium.org/137493008/. It's very conservative,
though, so it's unclear how often it would help.
chro...@googlecode.com
May 18, 2015, 10:56:05 AM5/18/15
to chromi...@chromium.org
Comment #121 on issue 166593 by jwba...@gmail.com: Frequently
@pauljensen: I hadn't seen your request. I am trying now to repro with
net-internals open.
Reply all
Reply to author
Forward
0 new messages