Hello Martin,
On Wed, May 19, 2021 at 7:09 AM Martin Mathieson via Wireshark-dev
<wireshark-dev@xxxxxxxxxxxxx> 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.
