From owner-freebsd-net@FreeBSD.ORG Thu May 21 14:51:16 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECCC61065670 for ; Thu, 21 May 2009 14:51:16 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id C5E048FC1D for ; Thu, 21 May 2009 14:51:16 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n4LENFl3088793 for ; Thu, 21 May 2009 07:23:42 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n4LEL9L6075683; Thu, 21 May 2009 07:21:09 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from [10.2.204.104] (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n4LEL8q8065610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 May 2009 07:21:09 -0700 (PDT) (envelope-from gnn@neville-neil.com) Message-Id: <43B043BD-4D7B-414B-91AB-3C8DBA0EC078@neville-neil.com> From: George Neville-Neil To: Zachary Loafman In-Reply-To: <20090519211346.GC675@isilon.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 10:21:07 -0400 References: <20090519211346.GC675@isilon.com> X-Mailer: Apple Mail (2.935.3) X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: ip=64.13.141.3; country=US; region=CA; city=Mountain View; latitude=37.3974; longitude=-122.0732; metrocode=807; areacode=650; http://maps.google.com/maps?q=37.3974,-122.0732&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: net@freebsd.org Subject: Re: [PATCH] SYN issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 14:51:17 -0000 On May 19, 2009, at 17:13 , Zachary Loafman wrote: > net@ - > > A short patch attached that requires 3 paragraphs of explanation. > > We found an issue in TCP when the a client connects to our server, > establishes a connection, reboots and chooses the same source port to > re-establish the connection. This isn't hard from other vendors' > clients. On Solaris, the same NFS mount order at boot time will > frequently result in source port re-use for the NFS connections. In > this case, the customer was seeing mounts hang until the keepalive on > our side would kick the established connection. > > The problem in the code is probably best explained using the patch > itself: > > --- > Index: sys/netinet/tcp_input.c > =================================================================== > --- sys/netinet/tcp_input.c (revision xxxx) > +++ sys/netinet/tcp_input.c (working copy) > @@ -1818,7 +1818,11 @@ tcp_do_segment(struct mbuf *m, struct tc > > todrop = tp->rcv_nxt - th->th_seq; > if (todrop > 0) { > - if (thflags & TH_SYN) { > + /* > + * If this is a duplicate SYN for our current > connection, > + * advance over it and pretend and it's not a SYN. > + */ > + if (thflags & TH_SYN && th->th_seq == tp->irs) { > thflags &= ~TH_SYN; > th->th_seq++; > if (th->th_urp > 1) > --- > > The problem is that when our TCP stack gets a SYN packet for a > connection that's already in ESTABLISHED state, it runs through the > above code. The above code is basically noticing that the packet is > coming in left of the receive window and then saying "Ah, a SYN! This > must be a duplicate SYN for our existing connect." After that, it just > turns off SYN and treats it as a normal packet (after advancing past > the SYN seq number). The code is broken, though: the only condition > under which this is a duplicate SYN is if the th_seq matches the irs, > the initial receive sequence. > > After correcting the above, any SYN that doesn't exactly match the > initial sequence number results in a RST|ACK response and the > ESTABLISHED connection being dropped. Before this change, this is also > what happened if a SYN arrived within or past the window, so I'm > basically making the before-window behavior match the other > behavior. I tested this using telnet to establish a TCP connection and > raw packet injection to throw SYNs at it. > > Comments? > Yes, nice catch. Best, George