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 ? Rgds, Gopa. On Wed, May 27, 2015 at 11:02 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2015-05-27 at 10:57 -0700, Eric Dumazet wrote: >> On Wed, 2015-05-27 at 10:29 -0700, Gopakumar Choorakkot Edakkunni wrote: >> > Thanks Eric. I will give this a spin. The issue doesnt happen all the >> > time, I can keep the server running with this patch for a while and >> > observe if the issue resurfaces or not >> >> Note that if the traffic on the server is low, you might want to keep a >> tcpdump running (capturing only headers for TCP port 443) for further >> analysis. > > We wonder if this could be a time-wait issue > > Could you check on the server : > > sysctl net.ipv4.tcp_tw_recycle > sysctl net.ipv4.tcp_tw_reuse > > Thanks > > -- 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
