Is your VM host running VMware? I just ran across this
https://stackoverflow.com/questions/52415943/trying-to-git-clone-via-ssh-but-getting-broken-pipe-error
which mentions that adjusting ServerAliveInterval and IPQoS in your ~/.ssh/config might help.
The issue that Jim mentions below was due to netfilter triggering RSTs on delayed or out of order packets. That might be the issue here as well, but that would be something for GitLab to fix:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/4849#note_587084318
On 5/19/21 6:53 AM, Martin Mathieson via Wireshark-dev wrote:
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.ws@xxxxxxxxx <mailto:jim.young.ws@xxxxxxxxx>> wrote:
Hello Martin,
On Wed, May 19, 2021 at 7:09 AM Martin Mathieson via Wireshark-dev
<wireshark-dev@xxxxxxxxxxxxx <mailto: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 <http://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@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx>>
Archives: https://www.wireshark.org/lists/wireshark-dev <https://www.wireshark.org/lists/wireshark-dev>
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev <https://www.wireshark.org/mailman/options/wireshark-dev>
mailto:wireshark-dev-request@xxxxxxxxxxxxx <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
