Hey there, I was just playing around with Wireshark on my home network and noticed an awful lot of TCP transmission and other black messages. This connection has been notoriously inconsistant and seemly stops working for web traffic every now and again until I reconnect (VoIP calls work consistantly however). I have attatched some logs below of me trying to access a website: https://www.cloudshark.org/captures/a366b9205ca8 Website loaded before returning an error https://www.cloudshark.org/captures/e96b45abe3c7 Webite loaded successfully after a long wait I'd appreciate any help as to what is happening here and any possible solutions, Thanks in advanced, Jack. asked 20 Oct '15, 15:51  jarthur36 |
One Answer:
Please take a look at the file catastrophicPacketLoss.pcapng and then apply the following display filter (click on the link to see it on cloudshark) You'll see continuous outgoing traffic, including DNS queries from 192.168.1.110 -> 192.168.1.1 (TP Link) and also to 8.8.8.8 (Google). Now, apply the following filter (click on the link to see it on cloudshark) You'll see only a few incoming frames. All TCP, no DNS answers and frames only once in a while. So, without knowing what's going on, here are some possible explanations:
Until you reconnect? Interesting! If you reconnect, you will 'reset' the link to the ISP and you will (most certainly) receive a new IP address. For me, this makes options 2. and 4. more likely than the others. 2. because a link reset might temporarily fix the problem at the ISP and 4. because if you receive a new IP address, the DoS/DDoS traffic (still going to the old IP address) will no longer end up in your internet pipe. Regards answered 22 Oct '15, 18:46  Kurt Knochner ♦ edited 22 Oct '15, 18:47 |
Yes only TCP seems to be affected by the packet loss. But what... the root cause is...
Have you checked your Firewall logs?
Dropbox & Origin should probably be turned off when you are looking for connectivity problems. Chrome is also spewing packets onto your line in QUIC, probably an addon?? Try starting chrome incognito and testing again. I'm not really very versed in MAC lore, I assume it does things the same but differently. However, dropbox causes quite a few false positives, it just isn't worth worrying about in the first analysis. Also, I have never seen a trace done at home without packet retransmissions etc, that's kinda expected.
I think Christian has a point. If you look at the trace catastrophic: There are only 7 incoming packet from outside your local network and they are flaky at best and then nothing until 64 seconds. A full stream 19 would have been really useful there :D
I would assume that A: a Firewall has shut you off for 60 seconds (maybe a response to an incoming packet storm, unlikely though. If it was Windows I'd say turn off ICS/Firewall or your AV solution...) B: Your provider did a line reset, look in the log on your router / firewall (Likely) c: Your provider did not provide very well for 60 seconds (Very Likely)
No Idea why your voip would work though? unless the TPLink router has 2 connects, one for voip and one for non-voip (I have never heard of one, but this means nothing.) I know that when I lose my provider connection, my phone dies too.
I can only see udp non tcp traffic to external addresses and I have no idea how the program sending it handles packet loss. It could be screaming out loud and you would not really know about it in the trace. You can see quite a few instances of 1 second between packets in the udp, always around the time TCP stalls, maybe that is packet loss handling?
Well, well seems that I have been yesterday a little bit to hastily. I think the udp traffic is affected, too.