Wireshark mailing list archives
Re: Having trouble cloning repo in a new VM
From: Jim Young <jim.young.ws () gmail com>
Date: Thu, 27 May 2021 18:28:15 -0400
Hello Gerald, On Thu, May 27, 2021 at 4:20 PM Martin Mathieson via Wireshark-dev <wireshark-dev () wireshark org> wrote:
I am using VirtualBox..
After discussing the conditions with Martin, I tried unsuccessfully to replicate the issue with a macOS VM running on Vmware Fusion with NAT. I had initially tried using an https based `git clone` but later tried using an ssh based `git clone`. Interestingly an https based `git clone` maintained the TCP session for the entire duration of all phases of the clone process. But when doing an ssh based `git clone` the TCP session would be closed gracefully after the 'Receiving' phase. The ssh phase never stalled long enough to drop the connection prematurely. With an Ubuntu VM running on VirtualBox with NAT I got the idea that I might be able to replicate some of the conditions by artificially stalling the ssh process at the 'Enter passphrase for key' prompt. From a pair of concurrent captures taken on each side of the VirtualBox NAT, there's some interesting differences in what one sees with the TCP packets. From the capture on the public side of the NAT, the server started sending TCP Keep-Alives every 15 seconds after the passphase prompt. After 90 seconds the server sent a TCP FIN which the client acked. But the session persisted for another 676 seconds until the client appeared to send a TCP FIN. From the capture taken on the VM the TCP Keep-alives are not seen. The server's TCP FIN is seen 90 seconds after stalling for the prompt. None of the server's TCP Keep-Alives were seen on the are seen by the client one TCP Keep-Alive is seen 7200 seconds (6 hours!) after the server's TCP FIN. The single TCP Keep-Alive seen by the client 6 hours after the TCP FIN was received triggered the client to send a TCP RST. The TCP RST was not seen on the public side of the NAT. Even though the client received the TCP FIN from the server, and that the client eventually sent a TCP reset, the git client running on the VM didn't exit by itself; it had to be terminated manually via a CTRL-C. I was somewhat surprised that git didn't exit when TCP FIN was received nor when the TCP RST was sent. It might be interesting to replicate with ssh diagnostics enabled. 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-request () wireshark org?subject=unsubscribe
Current thread:
- Having trouble cloning repo in a new VM Martin Mathieson via Wireshark-dev (May 19)
- Re: Having trouble cloning repo in a new VM Jim Young (May 19)
- Re: Having trouble cloning repo in a new VM Martin Mathieson via Wireshark-dev (May 19)
- Re: Having trouble cloning repo in a new VM Roland Knall (May 19)
- Re: Having trouble cloning repo in a new VM Martin Mathieson via Wireshark-dev (May 19)
- Re: Having trouble cloning repo in a new VM Gerald Combs (May 27)
- Re: Having trouble cloning repo in a new VM Martin Mathieson via Wireshark-dev (May 27)
- Re: Having trouble cloning repo in a new VM Jim Young (May 27)
- Re: Having trouble cloning repo in a new VM Martin Mathieson via Wireshark-dev (May 19)
- Re: Having trouble cloning repo in a new VM Jim Young (May 19)