Adrian  writes:
> New SD card with Buster installed, and things set up.
>
> Early this morning, the first rsync session ran, and failed in the
> usual way.
>
> I opened up sessions on the source (192.168.1.18) and target
> (192.168.1.118) machines, and started tcpdump running on both.  I then
> ran the rsync script on the source machine.
>
> From the source machine :
>
> No.     Time    Source  Destination     Protocol        Length  Info
[...]
> 46      8.402167        192.168.1.18    192.168.1.118   SSHv2   108
> Client: Protocol (SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u7)

That’s stretch’s SSH on .18 - which _shouldn’t_ be a problem...

[...]
.18 sends two 7240-byte packets:

> 1088    51.251912       192.168.1.18    192.168.1.118   SSHv2   7306
> Client: Encrypted packet (len=7240)
> 1089    51.251985       192.168.1.18    192.168.1.118   SSHv2   7306
> Client: Encrypted packet (len=7240)

.118 acknowledges their receipt (the Ack field advances by
14480=2*7240):

> 1090    51.254561       192.168.1.118   192.168.1.18    TCP     66 22
> ? 49878 [ACK] Seq=21816 Ack=1777043 Win=333952 Len=0 TSval=371553102
> TSecr=2778699177

It sends two 13032-byte packets in quick succession.  However, these two
packets don’t shown up in the tcpdump from the other end:

> 1091    51.254647       192.168.1.18    192.168.1.118   SSHv2   13098
> Client: Encrypted packet (len=13032)
> 1092    51.254679       192.168.1.18    192.168.1.118   SSHv2   13098
> Client: Encrypted packet (len=13032)

The silence from this point is hard to explain. In the absence of an
acknowledgement from .118, .18 should be retransmitting, and when it
gives up (as the RST below suggests it has) that should provoke some
kind traffic. And it’s certainly surprising not to see the final RST
shown below.

My current guess is that something has gone wrong in .18’s kernel
network stack, possibly related to the the packet size. Since I’m not up
for debugging the Linux IP stack, the only way I have to test this
theory would be to upgrade .18 to buster and see if gets better
(essentially: if there’s a bug that was fixed between the stretch and
buster kernels). I appreciate that this is “perturb the problem and see
if it goes away” but I don’t have a better suggestion at this point.

> From the target machine :
>
> No.     Time    Source  Destination     Protocol        Length  Info
[...]

.118 receives 10 1448-byte packets, the same number of bytes as the two
7240-byte packets sent by .18 - i.e. they were fragmented (by something
- probably .18 itself, but after tcpdump got a look):

> 2000    67.066461       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2001    67.066948       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2002    67.067082       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2003    67.067185       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2004    67.067279       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2005    67.067504       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2006    67.067565       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2007    67.067668       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2008    67.067718       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)
> 2009    67.067819       192.168.1.18    192.168.1.118   SSHv2   1514
> Client: Encrypted packet (len=1448)

.118 acknowledges these packets, the same packet seen in the other
log:

> 2010    67.068146       192.168.1.118   192.168.1.18    TCP     66 22
> ? 49878 [ACK] Seq=21816 Ack=1777043 Win=333952 Len=0 TSval=371553102
> TSecr=2778699177

...and nothing thereafter. The two 13032-byte packets do not appear.

Two hours later .118 asks if the session still exists and gets a ‘no’.

> 564216  7427.756675     192.168.1.118   192.168.1.18    TCP     66
> [TCP Keep-Alive] 22 ? 49878 [ACK] Seq=21815 Ack=1777043 Win=333952
> Len=0 TSval=378913834 TSecr=2778699177
> 564217  7427.757541     192.168.1.18    192.168.1.118   TCP     60
> 49878 ? 22 [RST] Seq=1777043 Win=0 Len=0

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05