* TCP TSecr question
@ 2009-04-10 16:24 Cosmin Ratiu
0 siblings, 0 replies; only message in thread
From: Cosmin Ratiu @ 2009-04-10 16:24 UTC (permalink / raw)
To: netdev
Hello,
There is an issue with this field in SYN packets when tw reuse/recycle
is on.
Quoting from RFC 1323, section 3.2:
The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option. When TSecr is not valid, its value
must be zero. The TSecr value will generally be from the most
recent Timestamp option that was received; however, there are
exceptions that are explained below.
On Linux, when the sysctl_tcp_tw_reuse or recycle is on, the most recent
timestamp from a previous connection is sent instead of 0. From what I've
seen in the source, this has to do with PAWS against delayed/duplicate SYN
packets.
My questions:
1) Is this violation of RFC 1323 useful in PAWS or did I misunderstand
the whole situation?
2) Is there any other RFC that amends 1323 to specify this behavior or is it
a Linux-specific enhancement?
Thank you,
Cosmin.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-04-10 16:40 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-10 16:24 TCP TSecr question Cosmin Ratiu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox