On 23/06/2014 8:24 PM, Petar Bogdanovic wrote: > ... > Now I'm thinking about compiling sshd with SO_DEBUG and a new kernel > with TCP_DEBUG but I'm not sure, what I'll be able to read from this. > > Any suggestions are very much appreciated, since I'm running out of > ideas and would like to avoid messing with the (production-)server > more than is really necessary. >
>From that capture file, there is only *one* packet with the FIN bit set (line 20076): 09:24:10.646480 IP (tos 0x0, ttl 64, id 6680, offset 0, flags [DF], proto TCP (6), length 1084) 85.X.X.X.22 > 77.X.X.X.59412: Flags [FP.], cksum 0x744b (correct), seq 8611816:8612848, ack 9744, win 4197, options [nop,nop,TS val 26 ecr 26], length 1032 which suggests that it isn't aligned with the normal pattern that you are seeing? (There are repeats later (RST packets) along with some sel-ack stuff.) So far as I can tell, this is not a retransmission of previous data and it is but maybe 2/1000 of a second after the last packet in that direction. Nothing should be idling. There is also no sign of TCP window stress so it seems unlikely to be due to buffering problems. Unfortunately your syslog message from sshd will not have enough resolution to determine which packets it is between in terms of time. You might want to look more closely at the TCP session shutdown with wireshark to see what it thinks. Or a better idea would be to capture everything in/out of that NIC and concentrate on the part around where the session shuts down. Darren