tcp: avoid sending zero TSval

Per RFC1323, zero TSecr is considered invalid. Thus we must avoid when possible sending a zero TSval.

Currently, we use the least significant 32 bits of jiffies to fill in TSval. But that can wrap around to zero (in 5 minutes after reboot, and every 49 days after that in the worst case).

This patch approximate a wrap-around zero TSval to 1. This is better then emitting a value which will be ignored.

---
 net/ipv4/tcp_output.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

index 4e00442..607d675 100644
@@ -415,7 +415,10 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
 				       (TCPOPT_TIMESTAMP << 8) |
 				       TCPOLEN_TIMESTAMP);
 		}
-		*ptr++ = htonl(opts->tsval);
+		/* Currently, opts->tsval always comes from tcp_time_stamp.
+		 * Thus, if zero, its caused by jiffie wrap-around, and we can
+		 * approximate it to one to avoid a later TSecr drop */
+		*ptr++ = htonl(opts->tsval?:1);
 		*ptr++ = htonl(opts->tsecr);
 	}
 

From: Octavian Purdila <[email protected]>
Date: Mon, 31 Aug 2009 20:44:56 +0300

Ok, I've changed my mind again. I think we need to go with a solution like this.

Even if we could somehow justify allowing zero timestamps, I just checked some other stacks and all of them ignore zero tsecr values. So we can't make that kind of change no matter what.

This patch needs some changes.

We have to adjust the tests we make against tsecr.

If we bump up a zero jiffies to one in an advertised timestamp, then we get back a tsecr value of one, and jiffies is still zero, we should use a comparison value of one not zero.

This is not trivial. You might think it's OK to handle all of this by just adjusting the definition of tcp_time_stamp but that gets used by a lot of other things in the stack so those side effects need to be analyzed.

Grepping around also shows that we also have some code that doesn't handle jiffies wraparound at all, f.e. check out the rcv_tsecr tests in net/ipv4/tcp_lp.c :-/