I am using VirtualBox. On Thu, May 27, 2021 at 6:29 PM Gerald Combs <ger...@wireshark.org> 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...@gmail.com > <mailto: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 <mailto: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 <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@wireshark.org > <mailto:wireshark-dev@wireshark.org>> > > 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-requ...@wireshark.org <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
