[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

  I am using VirtualBox.  

On Thu, May 27, 2021 at 6:29 PM Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:

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
>