Since a few days I get "ERR_CONNECTION_RESET" errors in Chrome and Firefox. Mainly with wikia.com and imgur.com After trying a lot of different approaches DNS flush, switching to openDNS, Router / Modem reset, registry cleaning, disable anti virus / firewall and whatnot I came up with no solution as of yet. I'm pretty sure it's not my PC though, since I have similar problems from my mobile phone. PC is connected via LAN, phone via WLAN. I did a capture and noticed a couple of errors:
And a lot of red and black bars in general. (I'm a total WS beginner) I uploaded the capture to my Dropbox ( Link to capture file ) and hopefully someone can finally tell me what the hell is wrong with my network. asked 29 Apr '16, 16:08  Tiiara edited 30 Apr '16, 14:21 |
2 Answers:
Looks to me like someone is preventing you from accessing certain web pages. E.g. if you filter on "tcp.stream==4" for the fourth TCP session you'll see that your GET request for "http://diealdor.wikia.com/wiki/Piixy" leads to a connection abort by a RESET packet from 23.235.37.194 (well, two actually), but right after that you get retransmissions for the SYN/ACK from that same IP. This makes no sense - if the server aborts the connection it won't try to resend "normal" packets afterwards. What seems to happen is that someone is monitoring/intercepting your network traffic and injecting reset packets to force connections to fail. The server doesn't know about that, of course, and tries getting the real packets through to you, which is why you see them coming in after the resets. It's interesting that other web page calls (e.g. to imgur.com) work, so it looks like only specific URLs are messed with. I don't know what network you're on, but if this at work, it may be a "prevent employees from accessing non-business websites" mechanism, but that's usually done via filtering proxy, not forged resets. So my guess is someone is messing with you, or just doesn't want you to visit certain resources. It must be someone with access to your communication, so check if there's something/someone in your own network who may be reponsible. Otherwise it would have to be someone outside your network who can monitor what you're doing. Maybe try to switch to HTTPS connections if you can, which makes it much harder to do something like this. Of course this can also be some sort of misconfiguration, but the incoming packets after the resets are very uncommon. answered 30 Apr '16, 00:18  Jasper ♦♦ showing 5 of 35 show 30 more comments |
How to fix ERR_CONNECTION_RESET Error Code Problem:-
answered 09 Jul '16, 22:07  rs372433 |
I am at home on my personal computer and I get Internet from our local cable provider. I checked again an the same happens on all our computers here. We use the following hardware to get online:
- Thomson TCM420 Cable Modem - SW Version: ST52.05.51 - SW Model: a806 - Bootloader: 2.1.6d - D-Link Systems DIR-645 Router - HW Version : A1 - FW Version : 1.01I checked the router and found no sign of any activity from this end that looks like someone monitoring / intercepting my traffic. The strangest thing is, that those websites not working in the log will work for a minute or two if I hit the refresh button often enough in rapid succession.
The idea of someone monitoring/intercepting my traffic and injecting stuff into my connection is horrible.
Any idea how I could confirm/refute this theory? Or even better, what I can do about it?
It's not that uncommon that rapid retries will get through every once in a while - injecting packets is not working 100% all the time, depending on the timing and other things.
I don't think the cable modem is at fault - modems just transfer data without messing with it. Maybe your router has a problem or even got hijacked. It has quite a list of known vulnerabilties, and some of them are affecting your FW version:
https://www.cvedetails.com/vulnerability-list/vendor_id-899/D-link.html
You should make a backup of the configuration of the router, then wipe it/factory reset it, and flash the latest firmware before reconfiguring it. Check if the problems goes away.
Thank you, I will try this over after lunch today.
Another thing, I just tried visiting those problematic websites via a free VPN from hide.me and didn't get any ERR_CONNECTION_RESET errors at all. I'll capture some tries later if the same problem occurs again but first I'll try the firmware update.
Depending on where the VPN starts encrypting (I guess on your PC) the intercept can't detect the URLs anymore you're accessing, so it doesn't react I guess.
I updated the firmware from 1.01 to 1.06 and so far it seems this did the trick. All this is really strange and I kinda fail to see a motive behind any deliberate attempt by some random person to block me from using some specific URLs. Whatever this was, I don't get it. Thanks for the help though!
Sooo.... no, this was kinda premature. Just a minute after the firmware update I get the same errors in my browser again.
This sucks. Any new ideas?
If you can, replace the router to see if that helps (maybe someone has a spare you can try). It's possible that a Firmwareupgrade and Factory Reset isn't good enough to get rid of whatever embedded itself.
You can also try to capture between Modem and Router (on the router's WAN side so to speak), but you'll need a TAP or Switch with a SPAN port for that, which may be not available to you. The idea is to see if the Reset packets are also seen on the WAN side, because if they're not, you know for sure that your router is doing it.
You also need to consider that whoever managed to get into the router has spread further into your network and is able to reestablish it's foothold by using other backdoors placed in PCs or other devices. It's kind of a nightmare scenario, but it would be unwise to totally deny it as a possibility.
A nightmare scenario indeed.
I did another capture just now and get the same error messages I got earlier. https://www.dropbox.com/s/hwz4c80le67islr/30.04.16_2.pcapng?dl=0 So now what do I do ... I'll order a new router from amazon (wanted a fritzbox anyway), which will arrive on monday, and hopefully this will help.
Another idea I just came up with: Can I try to unplug the router and connect my PC directly with the modem? Is that even possible? Then I would also know if it's the router's fault, right?
yes, good idea, connecting the PC directly should work. Maybe you need to reboot the modem when you do - I've seen modems only talking to one LAN MAC, so if it learned the router's MAC it will not accept your PC without a restart. And make sure the local firewall on your PC is running, because you're now directly connected to the BBI (Big Bad Internet) with it.
Fritzbox is a good move, they're much better when it comes to handling security the right way.
I connected the PC directly to the modem with nothing else active in the network. No router, no other devices, just the cable modem connected with a LAN cable to my pc. Same result. I still get the same
[TCP Spurious Retransmission], [TCP Retransmission], [TCP Previous segment not captured],[TCP Out-of-order]errors over an over again.So, if I understand it correctly, that means the problem is either with my PC in the form of some kind of malware / virus / trojan whatever that ALSO affected ALL other devices in our network (since I got the same errors with my android phone, tablet and second PC) or it is something wrong with my cable provider. Right?
Would the fact, that the VPN solution results in no errors at all conform with that?
According to the pcap file in dropbox, the TCP stream 4 has two RST. Note that they are not RST/ACK. This is strange too. As TCP RST (not RST/ACK, the ack numbers are 0). According to http://superuser.com/questions/602645/are-there-any-requirements-for-the-sequence-numbers-on-tcp-reset-packets, RFC 793 requires the ACK bit.
I just stumbled upon something while trying to find some more information about those strange reset flags. Something about Comcast in the US in late 2008. Then I noticed all those errors occurred on ports with really high numbers. For example:
Transmission Control Protocol, Src Port: http (80), Dst Port: 57877 (57877), Seq: 6506, Len: 0 Transmission Control Protocol, Src Port: http (80), Dst Port: 59305 (59305), Seq: 110627, Len: 0Could this be my ISP trying to use some kind of blocking system for the higher port ranges to counter p2p, file sharing or something like that? I still don't understand why it only happens on the wikia.com and imgur.com URLs though. Any way to test this?
Formally, no ports are "really high", as the port numbers range from 0 to 65535 (all the values that can be expressed in 16 bits) and the range currently suggested for ephemeral ports (those which TCP clients use locally to establish sessions towards servers) is 49152 - 65535.
To test whether the ephemeral port number plays a role in your puzzle, this is an article on how to set a different range for ephemeral ports on Windows; on other operating system, the way to do it is different but the goal is the same, to use lower port numbers.
Bear in mind that you should not restrict too much the total number of ephemeral ports to be used, as doing so could cause other issues - TCP uses protection mechanisms which require a certain rest time before the same port can be reused to set up a new session to the same server. So I'd recommend to set, say, 5000 ports starting from 40000, and before doing so, to close any other browser windows than the one necessary for testing. A single browser window may open many TCP sessions, with all those advertisement networks.
But I don't believe it will be the reason. The p2p filtering mechanism would normally act on sessions where both ends use high port numbers. If it is a broken one and so it only looks at one of them, 40000-44999 is still too high.
You've almost answered yourself, so much effort spent to ban you from two sites isn't proportional, so I'd suspect something at the ISP side (or at the side where the sites in question are hosted, I've seen such issues too).
As @Jasper wrote, unless the hypothetical malware is a stealth one and would like to hide from you, it should act the same on a VPN interface of your PC like on a physical interface. So the fact that with VPN the issue doesn't appear almost excludes that it would be caused by a malware on your PC. Besides, the incoming RST packets are shown in the capture, which is also not easy to accomplish for a software running on the PC on which you capture.
Thanks a lot for the link provided. I will try this tomorrow.
I also called my ISP yesterday but on their end everything is fine. I figured as much. They suggested sending a technician over to take a look at my network setup, but if he finds something wrong with it I have to pay the whole thing. I'm not looking forward to it, Murphy's Law an all that, but if nothing else gets me any results, might as well.
I doubt your ISP has technicians that can do packet analysis on a level as required (I may be wrong, though) - the ones I have seen are basically electrical engineers that can read a db/m graph to check if the physical signal is strong enough.
BTW I asked some other network forensics specialists for their thoughts on your trace and here's a quote from one of them:
"That's odd. I don't see a motive for someone to inject RST packets in those sessions, but that is clearly what is happening. My guess is that the RST packets are coming from the ISP rather than being a hacked cable modem."
As expected changing the port range didn't do anything. Talking to tech support was just as useless. The lady on the technical hotline tried to make me believe it's the modem dying of age. Yeah, right. I bet she didn't even understand half of what I told her about the problem. sigh Nevertheless I send the trace to tech support yesterday anyway and I'm really curious about what they'll say. Hopefully something useful.
I also noticed the error occurring more while using firefox and less while using chrome. They still occur on all browsers, I even installed IE and Safari to try those, but if I had to name a number I'd say on FF it's a 95% failure rate and on chrome only about 70%. Sometimes I can't reach those sites on FF but chrome works fine. A minute later both don't get response other than connection reset.
I really don't know where this will get me, but is there any way to be sure where those RST injects are coming from?
There is no way to be sure (as the injected packets have to look as if sent by the server in order to work, you cannot "geolocate" their source by their contents), but you could get some further inditia if you can extend your search.
At near end, it could be possible for you to ask a neighbouring friend who uses the same ISP to try the same. At far end, you'd have to contact the administrators of those affected sites and ask them for assistance.
A useful tool here is
traceroute(ortracerton Windows) which should disclose you the nodes (routers) on the paths through the internet between you and the servers. If the beginnings (the closest nodes) of these paths are the same at your friend's like your own ones, and the issue doesn't happen at your friend's, then the RST spoofing is most likely triggered by your network's public address; if the beginning of the path is different and the issue happens anyway, it is related to something else. In any case, the information from traceroute would be interesting for the site administrator.In my case, it looks like this (information about first 7 nodes manually removed):
Tracing route to wikia.com [23.235.37.194] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms xxxx private xxxx 2 1 ms 1 ms 1 ms xxxx private xxxx 3 87 ms 57 ms 67 ms xxxx private xxxx 4 * 69 ms 82 ms xxxx private xxxx 5 107 ms 102 ms 79 ms xxxx private xxxx 6 96 ms 100 ms 94 ms xxxx private xxxx 7 79 ms 88 ms 102 ms xxxx private xxxx 8 86 ms 81 ms 52 ms supernetwork.peering.cz [91.213.211.101] 9 90 ms 193 ms 89 ms vl5.sit-c76-edge2.superhosting.cz [88.86.96.209] 10 * 93 ms 89 ms be4402.ccr21.prg01.atlas.cogentco.com [149.6.24.41] 11 106 ms 90 ms 101 ms be2078.ccr42.ham01.atlas.cogentco.com [130.117.0.165] 12 206 ms 88 ms 104 ms be2798.ccr42.fra03.atlas.cogentco.com [154.54.58.229] 13 104 ms 102 ms 143 ms be2846.rcr22.fra06.atlas.cogentco.com [154.54.37.30] 14 147 ms 95 ms 234 ms be2844.rcr21.fra06.atlas.cogentco.com [130.117.0.30] 15 * * * Request timed out. 16 77 ms 92 ms 77 ms 23.235.37.194 Trace complete.And I have no problems whatsoever to access the first link on that site from your capture from Mozilla Firefox.
Before going to your friend's, use
traceroutewhile using the VPN connection; unless the RST spoofer watches for your public IP, the nodes closer to the far end which are common for the "normal" and "VPN" paths are not guilty.Strange Site. Can reproduce it. If I open the page, the computer produces more load then I have expected. And I can see the "RST Only" Packets in my trace, too.
It is in a way funny to see German users to be prevented from access to an obviously German site while an user from another country experiences no problems. Maybe someone has inverted the condition in
unless (hostname_by_ip($source_ip) matches ".de|.ch|.at") then ban()?Let's be serious again, @Christian_R, would you mind sharing your results of traceroute, to see what part of the path is common for both of us?
I tested the site as well before I wrote my first answer text, no problems at all (from Germany). Just tested again, still working.
Strange...Hm ok. The trace is gone I forgot to save... The only evidence that is left is a screenshot of the flag column... Ok it is a good example how a problem must not be analyzed. But what I can remember is that the page has loaded fine. And a moment later the browser shows me a blank window and the trace began to show me the Resets. I have made the test with Firefox at Mac OS 10.11
I will try to test it again as soon as possible. As I was in hurry I can't say for sure if I missed something while I have tested it.
@Jasper and @sindy In short: I can´t reproduce it. Because I missed one of the basic rule; Double check your findings.
So the most likely reason is that I mixed this two points:
- Sometimes I see, that the server sends a "RST only" after the 4Way session closing, to close his socket (As shown in Picture1:)
- If I open the page first time ever in a browser (tried 3 times) the User gets a blan browser tab (As shown in Picture2):
Picture1:
Picture2:
Okay... the aspect which has attracted my attention in your results is that while in your case, the server is 54.174.225.26, when taking my traceroute, the same fqdn got resolved to 23.235.37.194.
And now, from the office (still in .cz), I've got
;; ANSWER SECTION: wikia.com. 1511 IN A 23.235.33.194 wikia.com. 1511 IN A 23.235.37.194 wikia.com. 1511 IN A 104.156.81.194 wikia.com. 1511 IN A 104.156.85.194i.e. four distinct addresses but none of them matches yours... what does your
dig wikia.comanswer?Just to be sure, I've asked for the SRV record for _http._tcp.wikia.com, the DNS answer says "CNAME wikia.com.", so this is not the source of the difference.
@Tiiara, can you capture several attempts and check whether the successful ones differ from the unsuccessful ones by the IP of the server to which the session has been established? It's a shame but have no clue how Mozilla and other browsers handle the case when the DNS returns multiple IP addresses as an answer to an A-type query.
Two traceroutes:
Tracing route to wikia.com [104.156.85.194] over a maximum of 30 hops: (...censored...) 7 3 ms 8 ms 17 ms cz-prg-asbr1-be4.dialtelecom.cz [82.119.246.29] 8 2 ms 2 ms 2 ms prag-b3-link.telia.net [80.239.193.37] 9 3 ms 3 ms 2 ms prag-bb1-link.telia.net [213.155.132.164] 10 38 ms 159 ms 20 ms ffm-bb1-link.telia.net [213.155.132.240] 11 21 ms 20 ms 20 ms ffm-b1-link.telia.net [62.115.116.160] 12 * * * Request timed out. 13 21 ms 23 ms 21 ms 104.156.85.194 Trace complete.Tracing route to 23.235.37.194 over a maximum of 30 hops (...censored...) 7 12 ms 12 ms 2 ms cz-prg-asbr1-be4.dialtelecom.cz [82.119.246.29] 8 2 ms 2 ms 2 ms prag-b3-link.telia.net [80.239.193.37] 9 2 ms 2 ms 2 ms prag-bb1-link.telia.net [213.155.131.62] 10 20 ms 20 ms 20 ms ffm-bb1-link.telia.net [213.155.133.50] 11 20 ms 20 ms 20 ms ffm-b1-link.telia.net [62.115.116.164] 12 * * * Request timed out. 13 27 ms 28 ms 24 ms 23.235.37.194 Trace complete.So regardless the final destination, I go through telia, while from home I went through cogentco. In both cases I have no issues, but I don't know to which server I was actually connecting from home. In the office, Mozilla FF connected to 104.156.81.194 in all three attempts in new browser tabs.
@sindy: Forget the IP 54.... the IP has nothing to do with that case. It just sends an RST. That is what I wanted to tell with that example.
Of course I got the same 4 IP adresses for wikia.com as you. And I always go through telia with the last telia hop
ffm-b1-link.telia.net, too.A DNS lookup for wikia results in those 4 IPs:
104.156.85.194 104.156.81.194 23.235.33.194 23.235.37.194I did 4 trace routs to each of the IP addresses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tracing route to 104.156.85.194 over a maximum of 30 hops 1 7 ms 9 ms 8 ms xxxx private xxxx 2 11 ms 13 ms 17 ms xxxx private xxxx 3 13 ms 13 ms 14 ms xxxx private xxxx 4 13 ms 14 ms 11 ms 5-2-28.ear2.frankfurt1.level3.net [195.16.160.93] 5 13 ms 12 ms * te0-0-0-20.rcr21.fra06.atlas.cogentco.com [154.25.7.141] 6 * * * Request timed out. 7 13 ms 17 ms 13 ms 104.156.85.194 Trace complete. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tracing route to 23.235.37.194 over a maximum of 30 hops 1 16 ms 6 ms 5 ms xxxx private xxxx 2 10 ms 12 ms 10 ms xxxx private xxxx 3 11 ms 11 ms 12 ms xxxx private xxxx 4 18 ms * 17 ms gi0-0-0-19.nr12.b015760-1.fra06.atlas.cogentco.com [149.11.21.145] 5 12 ms 12 ms 12 ms te0-0-0-20.rcr21.fra06.atlas.cogentco.com [154.25.7.141] 6 * 13 ms 10 ms 23.235.37.194 Trace complete. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tracing route to 23.235.33.194 over a maximum of 30 hops 1 8 ms 12 ms 12 ms xxxx private xxxx 2 14 ms 11 ms 9 ms xxxx private xxxx 3 11 ms 14 ms 11 ms xxxx private xxxx 4 14 ms * 13 ms gi0-0-0-19.nr12.b015760-1.fra06.atlas.cogentco.com [149.11.21.145] 5 14 ms 14 ms 12 ms te0-4-0-5.rcr21.fra06.atlas.cogentco.com [154.25.7.145] 6 15 ms * 12 ms 23.235.33.194 Trace complete. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tracing route to 104.156.81.194 over a maximum of 30 hops 1 7 ms 10 ms 6 ms xxxx private xxxx 2 10 ms 13 ms 9 ms xxxx private xxxx 3 13 ms 11 ms 12 ms xxxx private xxxx 4 14 ms 17 ms 17 ms 5-2-28.ear2.frankfurt1.level3.net [195.16.160.93] 5 * * 13 ms te0-4-0-5.rcr21.fra06.atlas.cogentco.com [154.25.7.145] 6 13 ms 13 ms 12 ms 104.156.81.194 Trace complete. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~I also did some trace routs with nettols5 which resulted in the following screenshot:
I can try. Though I'm not entirely sure how. I hope those trace routs helped some already.
OK, so the first one is an unsuccessful try to connect to wikia.com
the second one is a successful attempt to connect to the site:
And the third one is something strange I saw after I just signed up for cloudshark but had the browser already closed. WS still tried to keep the connection alive and I think there are some RST flags in there too:
And here is WS capture while using my free hide.me vpn over the netherlands:
Maybe I missed it but I wanted to ask: If you got the error message, do you see a white browser screen before the error message is shown?
And what does the statusbar of the browser shows to you?
The traceroutes gave us the information that both you and me (from home) get to wikia's servers via cogentco but I don't have any issue while you do. So I would exclude the cogentco network as the source of non-targeted TCP reset spoofing. Your ISP and wikia administrators themselves remain the main candidates to me, as a network of a large interconnect operator seems a really unlikely source of targeted TCP reset spoofing to me.
There are no frames matching
tcp.flags.reset == 1. What do you mean by "WS still tried to keep the connection alive"? If WS means Wireshark, then no, Wireshark doesn't keep any connection as it only monitors the traffic (unless there is some Wireshark plugin unknown to me which allows to export files to Cloudshark directly and you had that one in mind). So I'd suspect most the browser process to shut down slowly and still perform some activity although its screen window has already been closed.If the VPN creates a virtual interface in your PC, you should capture at that interface. Otherwise there is no way to see the http (or any other) communication inside the VPN packets. It's one of main purposes of the VPN to encrypt the traffic, so the "plaintext" version of the traffic is only available between the VPN far end and the wikia servers, and at the VPN's virtual interface on your PC if it exists and WinPcap/libpcap can capture on it.
Sorry, I was too impatient. They are there, but they follow a FIN packet sent by your PC and are not followed by other packets sent by the server, so I wouldn't base any deep conclusions on them.
The "specialists" from my ISP called today and will change my cable modem. If that doesn't help they'll call me again an provide me with exact instructions on how to perform some specific tests with Wireshark. I'll keep you up to date if the modem exchange solved the problem.
Just as expected. Changing the cable modem did jack. sigh Tech support hotline it is. Again.
Just out of curiosity, have you ever tried to delet the cookies in your browser? And well I know, it has nothing to do with the RST, but maybe with the KEEP ALIVES.