Adrian  writes:
> strace on the target was started first.

Putting it into order, with [S] and [T] for source and target:

[T] 10:36:56.750037 select(12, [3 5 9 11], [], NULL, NULL) = 1 (in [3])
Target is waiting for something to happen.

[S] 10:37:20.669664 _newselect(7, [3 4], [], NULL, NULL) = 1 (in [3])
Source is waiting for something to happen.

[S] 10:52:56.730243 read(3, 0x7ee59f44, 8192) = -1 ETIMEDOUT (Connection timed
out)
15 minutes 36 seconds later, source gets a socket-level read error. This
probably means the kernel has been trying to send to the target but not
getting any response.

[S] 10:52:56.731099 write(3,
"\0i\201\205\372Zs\335\20\200\344\252'E8(\346\321\241\2155\341\274\235\371S\230
je\25\222U"..., 56) = -1 EPIPE (Broken pipe)
Source tries to write something (presumalby a shutdown message) but the
socket is bust, so it fails.

[S] 10:52:56.731464 write(2, "packet_write_wait: Connection to"..., 69) = 69
[S] 10:52:56.731706 exit_group(255)         = ?

Source errors out.

[T] 12:36:52.915631 read(3, 0xbe8f7054, 16384) = -1 ECONNRESET (Connection
reset by peer)

2 hours after the starting point the target’s kernel has given up on the
source (which is already long dead). 2 hours (probably) reflects the
default TCP keepalive time.


Whatever went wrong had already happened by 10:37:20. I agree with
Martin that applying wireshark or tcpdump is the next move. In
particular look out for packets that one end sends but the other does
not receive.

Do both hosts have the same link mtu? ‘ip link show’ should display
this.

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

--- SoupGate-Win32 v1.05