On Wed, 2015-05-27 at 11:15 -0700, Gopakumar Choorakkot Edakkunni wrote: > Doesnt seem so. This is the output from one of the servers I have > where I periodically hit this TSval != TSecr condition. > > ubuntu@server:~$ sudo su > root@server:/home/ubuntu# sysctl net.ipv4.tcp_tw_recycle > net.ipv4.tcp_tw_recycle = 0 > root@server:/home/ubuntu# sysctl net.ipv4.tcp_tw_reuse > net.ipv4.tcp_tw_reuse = 0 > > Also I dont think your theory about port-reuse is what is happening > either - because as I mentioned, its a very very lightly loaded > server, and the client is also very very light weight in terms of tcp > connections (makes one connection every 30 seconds to this one server > and no one else). But the reason I mentioned the SYN-ACK-lost + > SYN-retry theory is because the client<-->server is over internet via > standard broadband links shared across multiple people and hence can > be quite lossy. > > At any rate, whatever is the cause behind this, I guess what you > mentioned still holds good - that the tcp stack needs to update the > saved TSval to that of the latest SYN, right ?
Well, considering ISN is the same, I really doubt these are different sessions. tcpdump traces were taken on the server ? So far, nothing really calls for SYNACK rtx carrying different TSecr, RFC says nothing about this case, so either choice is valid. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
