From patchwork Wed Mar 11 15:00:02 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 24305 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 1D00EDE18B for ; Thu, 12 Mar 2009 02:00:23 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753135AbZCKPAS (ORCPT ); Wed, 11 Mar 2009 11:00:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753069AbZCKPAR (ORCPT ); Wed, 11 Mar 2009 11:00:17 -0400 Received: from gw1.cosmosbay.com ([212.99.114.194]:54586 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752304AbZCKPAQ convert rfc822-to-8bit (ORCPT ); Wed, 11 Mar 2009 11:00:16 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw1.cosmosbay.com (8.13.7/8.13.7) with ESMTP id n2BF02CK017615; Wed, 11 Mar 2009 16:00:03 +0100 Message-ID: <49B7D1F2.5090504@cosmosbay.com> Date: Wed, 11 Mar 2009 16:00:02 +0100 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Miller CC: netdev@vger.kernel.org, ilpo.jarvinen@helsinki.fi Subject: Re: [RFC] tcp: allow timestamps even if SYN packet has tsval=0 References: <49B7ABF2.5040803@cosmosbay.com> <20090311.064710.255854254.davem@davemloft.net> In-Reply-To: <20090311.064710.255854254.davem@davemloft.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Wed, 11 Mar 2009 16:00:03 +0100 (CET) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org David Miller a écrit : > From: Eric Dumazet > Date: Wed, 11 Mar 2009 13:17:54 +0100 > >> So apparently WindowsXP sends a NULL tsval in SYN packet, then >> subsequent packets get a real value (60498) in this case. >> >> This seems to work on other OS as well, so is the following patch >> considered evil ? Do we have security concerns or only risking >> windows client to have slightly wrong rtt estimation at the begining >> of the tcp session ? > > I think we'll have to accept this. > > I don't see other systems blocking initial ts_ecn values of > zero like we do. ts_ecn ? You meant tsval ? OK, here is a patch against net-next-2.6 with a Changelog and Signoff then. Thank you [PATCH] tcp: allow timestamps even if SYN packet has tsval=0 Some systems send SYN packets with apparently wrong RFC1323 timestamp option values [timestamp tsval=0 tsecr=0]. It might be for security reasons (http://www.secuobs.com/plugs/25220.shtml ) Linux TCP stack ignores this option and sends back a SYN+ACK packet without timestamp option, thus many TCP flows cannot use timestamps and lose some benefit of RFC1323. Other operating systems seem to not care about initial tsval value, and let tcp flows to negotiate timestamp option. Signed-off-by: Eric Dumazet --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index cf74c41..4a55854 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -1226,15 +1226,6 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb) if (want_cookie && !tmp_opt.saw_tstamp) tcp_clear_options(&tmp_opt); - if (tmp_opt.saw_tstamp && !tmp_opt.rcv_tsval) { - /* Some OSes (unknown ones, but I see them on web server, which - * contains information interesting only for windows' - * users) do not send their stamp in SYN. It is easy case. - * We simply do not advertise TS support. - */ - tmp_opt.saw_tstamp = 0; - tmp_opt.tstamp_ok = 0; - } tmp_opt.tstamp_ok = tmp_opt.saw_tstamp; tcp_openreq_init(req, &tmp_opt, skb);