Hello, Nikolaus Rath a écrit : > > I'm having trouble with an internet connection that seems to randomly > "freeze" arbitrary tcp connections when they have not been used for a > while. The connections stay established, but no data is coming through.
How long is "a while", at a minimum ? > When this happens, netstat still shows the connection status as > `ESTABLISHED` on both the local computer: > > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name Timer > tcp 0 53 192.168.0.10:41129 173.255.235.238:143 > ESTABLISHED 8219/gnutls-cli on (79.31/13/0) > > ..and the remote server: > > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name Timer > tcp 0 0 173.255.235.238:143 68.5.174.98:41129 > ESTABLISHED 5303/imapd off (0.00/0/0) It appears that the client has a private addresse and the server has a public address. So I guess that there is a NAT device between them, and its stateful NAT engine may be the cause of the problem, by deleting connections from its translation table after a delay of inactivity. > When I look at a packet capture of this connection on the client side, > there is a long (expected) period of inactivity that seems to trigger > the problem, then the local end tries to transmit some data again but > never receives an ACK. Instead, 15 TCP Retransmissions go out, with > intervals increasing from 0.3 seconds to 120 seconds. No activity is > captured after that. Can you do a packet capture on the server side well ? > Does anyone have a suggestion of how I could debug this further to find > out where the problem lies and how to fix it? > > Also, is is there some way to globally reduce the timeout on client > and/or server to reduce the time before the local application aborts? The Linux kernel supports system-wide TCP keepalive. However the application must enable it on a per-socket basis, and the minimum recommended value of 2 hours (which is the default in Linux) is quite high, the inactivity timeout in your NAT device may be shorter. The best workaround for this is to generate traffic with some kind of application-level keepalive, either defined in the application protocol such as in SSH, of by periodically sending dummy commands or data. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50cc5226.8040...@plouf.fr.eu.org
