Try changing other aspects of the connection, using other services, to narrow down what's wrong.Posted on March 18, 2023, 12:59 p.m. try to update drivers or boot from a linux live CD and see if the same thing happens.Is your friend running an exotic firewall that could be turned off? Does the ISP have some usage rules? 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.Check by using another service at the same time and see if it's affected by the outage too. if the connection is over a bad public wifi or 3G, then you can get brief periods of 100% packet drop.It would mean there are 2 problems instead of 1.) (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. 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. 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 MTU configuration can't be the cause of the problems. 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.Įdit: Just now, the git pull is working fine again. Could the packets be too large so they are stuck at the router?Īlso, mostly secure connections (https, ssh) seem to be affected but those could always require larger packet sizes, too. I can't configure the router for a MTU larger than 1500. 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 have a feeling that the cause of this is also the cause of all other networking issues of the LAN. Either the server isn't receiving the packet from my machine or my machine isn't receiving its answer. The TCP Retransmissions always start when the key exchange is initiated. Here is what the Wireshark log of the git pull looked like:

I finally came up with a reproducible problem, a git pull over ssh that didn't work. I've monitored the traffic for some time using Wireshark. The Internet connectivity is very slow and unreliable and sometimes services simply don't work. I'm currently investigating network issues of a friends LAN ( again).

Tcp dup ack wireshark