netdev - Re: Bug in tcp timestamp option ? TSecr in SYN-ACK != TSval in SYN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1432760731.4060.427.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 27 May 2015 14:05:31 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Gopakumar Choorakkot Edakkunni <gopakumar.c.e@...il.com>
Cc:	netdev@...r.kernel.org, Yuchung Cheng <ycheng@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Van Jacobson <vanj@...gle.com>
Subject: Re: Bug in tcp timestamp option ? TSecr in SYN-ACK != TSval in SYN

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@...ver:~$ sudo su
> root@...ver:/home/ubuntu# sysctl net.ipv4.tcp_tw_recycle
> net.ipv4.tcp_tw_recycle = 0
> root@...ver:/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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html