You can try to just capture a single depth (--depth 1) and see if this works
regards Roland Am Mi., 19. Mai 2021 um 15:54 Uhr schrieb Martin Mathieson via Wireshark-dev <wireshark-dev@wireshark.org>: > 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
___________________________________________________________________________ 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
