Hello Gerald,
On Thu, May 27, 2021 at 4:20 PM Martin Mathieson via Wireshark-dev
<wireshark-dev@xxxxxxxxxxxxx> 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.