From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 20:22:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906A81065673 for ; Sat, 15 Nov 2008 20:22:14 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2C92D8FC28 for ; Sat, 15 Nov 2008 20:22:13 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.6] ([129.247.12.6]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Nov 2008 21:08:56 +0100 Message-ID: <491F2C47.4050500@dlr.de> Date: Sat, 15 Nov 2008 21:08:39 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2008 20:08:56.0118 (UTC) FILETIME=[FD223D60:01C9475D] Subject: TCP and syncache question 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: Sat, 15 Nov 2008 20:22:14 -0000 Hi, in tcp_syncache.c:syncache_expand() there is a test that the acknowledgement number and the sequence number of an incoming ACK segment are in the expected range. If they are not, syncache_expand() returns 0 and tcp_input drops the segment and sets a reset. So far so good. But syncache_expand() also deletes the syncache entry, and so destroys the connection. I cannot see why it does it. It seems to me that such a wrong segment should be interpreted as to be from another connection and as such the segment should be ignored (but a reset sent). When the correct ACK comes, the connection could still be established. As it is now, the establishment of incoming connections can seriously be disturbed by someone sending fake ACK packets. The same test (for the ack number, not for the sequence number) is also further down in tcp_input.c:tcp_do_segment() (just after the header prediction stuff) and here the handling is correct: the goto dropwithreset just sends a reset and drops the segment but leaves the connection in the SYN-RECEIVED state. This test is probably never reached now, because of syncache_expand(), though. Maybe I fail to see something obvious, though... harti