Thanks, this got me going. Martin On Wed, May 19, 2021 at 5:27 PM Roland Knall <rkn...@gmail.com> wrote:
> 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
