This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP Dup ACK / TCP Retransmission

0

Hey all

I'm new to this whole Wireshark / internet problem solving thing so go easy on me. I have currently been having issues with my internet in regards to a 5-15% packet loss that comes and goes whenever it pleases. I Had a Telstra (ISP) technician check the line connecting my house to the road line and all was fine on their end of things. I switched to a brand new modem and the problem went away for 2-3 weeks then it started occurring yesterday out of nowhere.

Here is the capture for my local area network (Ethernet connection) :

https://www.cloudshark.org/captures/bd644f6be8fb

I tried to interpret all the numbers but I'm not experienced enough to know what to look for. Any help would be appreciated / comment for any information I need to add.

asked 27 Nov '15, 03:27

HarrisonT's gravatar image

HarrisonT
6112
accept rate: 0%


2 Answers:

0

Work from 'the ground up' so to speak. Go over all cables, connectors, power supplies and other networking gear to make sure these are up to par (you wouldn't believe the trouble bad cables can bring).

If that all checks out go check all network interface configurations. Are they configured the same (Speed, duplexity, MTU, etc.). Ie. connecting one end as auto-configuration and the other fixed doesn't result in a working setup, oddly enough.

If that all checks out go find a well defined scenario in which the problem can be reproduced. This may be tricky to do with intermittent problems, but usually will start to point in a certain direction.

Then if you have that scenario and can capture that add these details to the question and maybe an analysis can be made from that.

answered 27 Nov '15, 05:09

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

I went through and replaced all the cables isolating each one and it turned out to be the ADSL cable. Feel like a bit of a goofball not doing that before I posted this question, my apologies. Thanks for the simple but effective advice :)

(27 Nov '15, 18:41) HarrisonT

0

From this short capture it is hard to even spot any packet loss. Yes, the packet in frame 52 is a retransmission of packet in frame 23, but the other retransmissions are caused by the MTU negotiation - your PC has sent a packet which was too big for your router to be transported as a whole, so the home router has sent back an ICMP message asking your PC to split the packet in two smaller ones ("fragment" it), and the PC has sent the same data in two packets, and Wireshark has marked these two smaller packets as a retransmission of the first bigger one, which is correct, except that it may be misleading without taking the context into account.

So there can actually be more cases like this, and you'd need to provide far more data to say whether there is really a packet loss somewhere or only your misinterpretation of what Wireshark is telling you.

Plus you have to bear in mind that the packet loss can occur anywhere between your PC and the remote server, so to check the quality of your line connecting you to the ISP, you'd need to track communication between your home router and the LAN of the ISP's PoP. Ping test should be enough & only available for that purpose as you'd hardly find any tcp server in the PoP LAN which you'd be allowed to connect to.

In another words, even if there really is a packet loss, your ISP may be really innocent and the packet loss may happen between them and the web server you connect to, or already your home router may not handle the volume traffic you ask you to, or the ISP is guilty and the xDSL line is noisy or... So the general rule is to split the path into as many sections as you can and isolate the section which causes the trouble.

Also bear in mind that if the line speed is much lower than the LAN speed and your PC sends more packets than "fit" into the bandwidth of the line, to drop them is the only possible action taken by the router once it exhausts its buffers intended to accommodate for bursts of traffic which exceed the line capacity only for a short period of time. Some protocols (like tcp) provide a feedback to the sending side, effectively accommodating the sending speed to line bandwidth, some don't.

answered 27 Nov '15, 05:26

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%