I did take a capture. All I see is a FIN,ACK from the server, after which it sent another couple of ACKs. There are lots of 'TCP Window fulls' detected from the server end.
I tried with ethernet plugged directly into my home router, but the outcome was the same. Also disabled company VPN. Martin On Wed, May 19, 2021 at 2:21 PM Jim Young <jim.young...@gmail.com> wrote: > Hello Martin, > > On Wed, May 19, 2021 at 7:09 AM Martin Mathieson via Wireshark-dev > <wireshark-dev@wireshark.org> wrote: > > ... when I try to clone it starts to go through the stages (i.e. > counting/compressing/ receiving objects/resolving objects) I am told > 'Connection to gitlab.com closed by remote host' ... > > > > Any ideas? > > Have you made a pcap? ;-) > > Seriously it might give you a clue as to what side may be responsible > for the issue. > > Several years ago (~April thru June 2017) I was having intermittent > problems simply doing a `git pull`. At times I would have to retry the > `git pull` a dozen times or more before it would complete > successfully. A client side packet capture showed that my machine was > receiving TCP RSTs purportedly generated by the git server. These TCP > RSTs had an IP TTL value one higher than the other TCP packets from > the `git pull` conversation. The IP TTL value in the RST packets > implied some middle box was responsible for synthesizing the TCP RSTs. > Interestingly there were lots of TCP RSTs, but most of them were > "benign". The benign RSTs did not cause the TCP session to stop > prematurely because the TCP sequence number in the RST packets were > apparently "too old" (had already been acknowledged) and were > ultimately ignored by the TCP stack. But occasionally these TCP RSTs > would actually cause the TCP connection to fail and the git client > would ultimately time out. I managed to contact the git server admin > ;) and we coordinated a packet trace on the server side. We determined > that a middle box would generate the TCP RSTs when the git client's > TCP packets arrived out-of-order. A config change was made on the > middle box to its tcp connection tracking which ultimately resolved > the intermittent `git pull` issues. > > Best regards, > > Jim Y. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
