Message ID | 49B7ABF2.5040803@cosmosbay.com |
---|---|
State | Superseded, archived |
Delegated to: | David Miller |
Headers | show |
From: Eric Dumazet <dada1@cosmosbay.com> 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. -- 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
On Wed, 11 Mar 2009, David Miller wrote: > From: Eric Dumazet <dada1@cosmosbay.com> > 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. What about the fact that PAWS could bite us leaving us a hung connection if timestamp changes too much when we get the first ACK? Though I doubt you can get windows to run long enough for this to become a problem if they always start from zero... ;-)
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET) > On Wed, 11 Mar 2009, David Miller wrote: > > > From: Eric Dumazet <dada1@cosmosbay.com> > > 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. > > What about the fact that PAWS could bite us leaving us a hung connection > if timestamp changes too much when we get the first ACK? Though I doubt > you can get windows to run long enough for this to become a problem if > they always start from zero... ;-) I really don't think it's a real issue, and Windows XP should be happy we're willing to try timestamps at all with it :-) -- 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
On Fri, 13 Mar 2009, David Miller wrote: > From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> > Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET) > > > On Wed, 11 Mar 2009, David Miller wrote: > > > > > From: Eric Dumazet <dada1@cosmosbay.com> > > > 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. > > > > What about the fact that PAWS could bite us leaving us a hung connection > > if timestamp changes too much when we get the first ACK? Though I doubt > > you can get windows to run long enough for this to become a problem if > > they always start from zero... ;-) > > I really don't think it's a real issue, and Windows XP should be happy > we're willing to try timestamps at all with it :-) Right. Would it ever become a problem it would certainly possible to collect the first real timestamp and discard the bogus zero. We just need to be aware on this if some report about unable-to-connect appears once the change gets larger exposure in wild. There could be other broken things such as firewalls zeroing it in SYNs so the end host might not necessarily even be xp.
Ilpo Järvinen a écrit : > On Fri, 13 Mar 2009, David Miller wrote: > >> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> >> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET) >> >>> On Wed, 11 Mar 2009, David Miller wrote: >>> >>>> From: Eric Dumazet <dada1@cosmosbay.com> >>>> 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. >>> What about the fact that PAWS could bite us leaving us a hung connection >>> if timestamp changes too much when we get the first ACK? Though I doubt >>> you can get windows to run long enough for this to become a problem if >>> they always start from zero... ;-) >> I really don't think it's a real issue, and Windows XP should be happy >> we're willing to try timestamps at all with it :-) > > Right. Would it ever become a problem it would certainly possible to > collect the first real timestamp and discard the bogus zero. We just need > to be aware on this if some report about unable-to-connect appears once > the change gets larger exposure in wild. > > There could be other broken things such as firewalls zeroing it in SYNs > so the end host might not necessarily even be xp. > If you believe this could cause unable-to-connect problem, we must revert the patch, or implement your work-around :) Thanks -- 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);