TCP Dup ACK/Retransmission, bad configuration?

Question

I'm currently investigating network issues of a friends LAN (again). The Internet connectivity is very slow and unreliable and sometimes services simply don't work.

I've monitored the traffic for some time using Wireshark. I finally came up with a reproducible problem, a git pull over ssh that didn't work. Here is what the Wireshark log of the git pull looked like:

The TCP Retransmissions always start when the key exchange is initiated. Either the server isn't receiving the packet from my machine or my machine isn't receiving its answer. I have a feeling that the cause of this is also the cause of all other networking issues of the LAN.

One thing I came up with is the packet length of 1514, while having the don't fragment bit set, of all bad packets here but the LANs router is configured for a MTU of 1492. I can't configure the router for a MTU larger than 1500. Could the packets be too large so they are stuck at the router?

Also, mostly secure connections (https, ssh) seem to be affected but those could always require larger packet sizes, too.

You see, I don't have a lot of experience with networking, so I hope some of you with more experience are able to make more sense of this.

Edit: Just now, the git pull is working fine again. The MTU configuration can't be the cause of the problems...

Solution 1

Large packets with "don't fragment" are normal. That's how the OS performs MTU discovery – instead of letting the network quietly fragment the packets, it expects an ICMP "Fragmentation required" error to be returned (which would have the correct MTU).

If you see the large packets getting retransmitted, it means some router in the middle is misconfigured and either blocks the ICMP error packets, or doesn't send them when needed.

Solution 2

I think a duplicate ack happens only when the receiver sees a gap in the sequence numbers, meaning a packet was dropped on the way to it; so the problem starts in the direction from 192.168.0.8 to the remote server. The fact that there are no acks (not even duplicate acks) back despite several retransmissions probably means that something is totally screwed in that direction. (It could mean that the remote side can't send but that is not consistent with the duplicate ack earlier, nor with the fin-ack later. It would mean there are 2 problems instead of 1.)

Here are some ideas:

• if the connection is over a bad public wifi or 3G, then you can get brief periods of 100% packet drop. Check by using another service at the same time and see if it's affected by the outage too.
• there are protocol-aware firewalls which may take a little while to work out what you are doing before they decide to drop packets on a particular connection. Is your friend running an exotic firewall that could be turned off? Does the ISP have some usage rules?
• try to update drivers or boot from a linux live CD and see if the same thing happens. Try changing other aspects of the connection, using other services, to narrow down what's wrong.

Comments

[Mouagip]

I strongly suspect the router in the LAN is causing these problems. I don't know if it is misconfigured or simply broken. As far as I can tell there is no firewall enabled so it shouldn't affect the traffic at all. Maybe there is a hardware problem. Probably there is no way around replacing the router to see if the problems persist.

[Mouagip]

It's a private Wifi network so the connectivity should be fine. A firewall is also not enabled, otherwise is should always not work and not "only" most of the time. The problems occur on different machines with different OS-es. As I said I suspect either a misconfiguration or a hardware problem of the router. Probably the easiest way would be to replace it and see if the problems persist.