From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 10:58:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71F6F16A4D0 for ; Thu, 14 Dec 2006 10:58:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B73D43DA6 for ; Thu, 14 Dec 2006 10:55:29 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 82046 invoked from network); 14 Dec 2006 10:44:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Dec 2006 10:44:08 -0000 Message-ID: <45812E01.9060200@freebsd.org> Date: Thu, 14 Dec 2006 11:57:05 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Julian Elischer References: <458094E7.1060806@elischer.org> In-Reply-To: <458094E7.1060806@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: question for TCP gurus (in ipfw) 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, 14 Dec 2006 10:58:08 -0000 Julian Elischer wrote: > in the ipfw function send_reject6() we go to great length to calculate > the sequence number to put into the ack field of the reject packet.. > > but it's a RESET we are generating.. > > do we need to go to all the work of setting the ACK value etc? Yes, at least some of it. > could we do either of: > 1/ not set the ACK bit and just not do the extra work. Just send a reset? Doesn't work. > or > 2/ instead of ACKing all the data in the packet we are resetting, > how about just ACKing the sequence number it starts with > and saving ourselves from doing the work of ACKing all the data > up to the current packet end. (which is the packet we are rejecting > anyhow) (It takes some calculation to work out the new ack value > which seems pointless as we are rejecting it..) Section 3 of this document describes the situation and requirements quite accurately: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt -- Andre