From owner-freebsd-net@FreeBSD.ORG Sat Nov 15 22:19:58 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 9FDD91065679 for ; Sat, 15 Nov 2008 22:19:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC348FC12 for ; Sat, 15 Nov 2008 22:19:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so151308ugs.39 for ; Sat, 15 Nov 2008 14:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=2UsOZcjROuxSFOP4g9T30RBY50wAWsv82td1D1DPsXc=; b=s5PNcpyfGLPkihw+H7mDWZZpOD78Bp5GnlT12XnBT1jTnAB1oKalJiDpjMUyw6s7D0 k933bvvLR/GfahxxkbulSQbVfHzX58x9qgGxCio9e3SZ7NlSG98f8qapnSaGOj2osE32 +tJadME48NqJAFu7Xo0KN7FAvSBjycHtHNBIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=BpmPSwHzheEowNTXfmNxk9uR07xKrojTP/LOgkMLBfzpK4s75ODpz/tuoFZ62F/2vV 4Zx6TgSzdEDrVAoz1+AAbrgnpR3PmsGUscadOPfcyHyvwqkqWUG40Z6lQj5SoHos66ee p7zP09J1rhVkPjtdUTROKnFz/PSejgNZthB8g= Received: by 10.210.73.12 with SMTP id v12mr2475334eba.107.1226785897732; Sat, 15 Nov 2008 13:51:37 -0800 (PST) Received: from ?10.0.0.15? ([83.144.140.192]) by mx.google.com with ESMTPS id t2sm3785163gve.5.2008.11.15.13.51.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 13:51:36 -0800 (PST) Message-Id: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> From: Rui Paulo To: Hartmut Brandt In-Reply-To: <491F2C47.4050500@dlr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 21:51:33 +0000 References: <491F2C47.4050500@dlr.de> X-Mailer: Apple Mail (2.929.2) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: 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 22:19:58 -0000 On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > 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... Well, if the RST is sent, why should we keep the syncache entry? Regards, -- Rui Paulo