On Mon, 2018-02-26 at 17:49 -0800, Nathan Anderson wrote:
> The reason I ask about NAT is because depending on how this timeout
> is manifesting, it could be the NAT. Is it an SSH session that only
> times out after it has gone idle for a few minutes? Or does it time
> out while it is actively in the middle of a data transfer?
What I did this time was run rsync (over SSH as usual) and on the
server side monitor rsync via strace. What I found was interesting. The
connection is killed ("timeout in data send/receive", claims the
client) somewhere. But interestingly even after the connection has died
on the server side rsync is still running and trying to iterate over
the files it was trying to sync according to strace, except that each
all of the file I/O (e.g. lstat64) bails with ENOENT for a few more
minutes before finally terminating due to a broken pipe (EPIPE).
Up until it closes I see regular keep alive packets being sent from the
client to the server.
It stands to reason that neither the client nor the server appear to be
terminating the connection, but likely something in between.
> If it's timing out in the middle of a transfer, it *could* be MTU.
>
> If it's timing out after it idles for a set amount of time, that is
> almost surely your NAT router deleting the connection tracking
> information for that TCP session from its local table. On some
> not-crappy routers, these connection tracking timeout values can be
> tweaked.
I suspect that the router is indeed crap, but I will try to investigate
further.
--
Kip Warner | Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.cartesiantheatre.comAttachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
