From owner-freebsd-net@FreeBSD.ORG Fri May 6 16:24:32 2011 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 71CC41065674 for ; Fri, 6 May 2011 16:24:32 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate.funkthat.com [70.36.235.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4E68FC2A for ; Fri, 6 May 2011 16:24:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id p46G9d2W076505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 09:09:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id p46G9cVq076503; Fri, 6 May 2011 09:09:38 -0700 (PDT) (envelope-from jmg) Date: Fri, 6 May 2011 09:09:37 -0700 From: John-Mark Gurney To: Cole Message-ID: <20110506160937.GN90732@funkthat.com> Mail-Followup-To: Cole , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 06 May 2011 09:09:39 -0700 (PDT) Cc: freebsd-net@freebsd.org Subject: Re: kernel module, TCP state, and mbuf 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: Fri, 06 May 2011 16:24:32 -0000 Cole wrote this message on Fri, May 06, 2011 at 15:49 +0200: > Im currently working on a kernel module to modify data on tcp sessions > leaving and coming into the box. And I have this working. However I've > run into the issue where I am now breaking the TCP state. > When I modify the data in the tcp packets, the size of that data may > change, meaning that I have to then update the packet size and so > forth. Now this works for the first packet with data inside it, but > the rest of the packets leaving on this TCP stream then have the error > where their sequence number is now wrong. i.e. If I modify the data, > and the new data size is then less than that of the original packet, > that means the next sequence number of the out going packet will > actually be higher than it should be, and the other side will think it > has missed a packet somewhere. Why not keep a delta sequence number and always update the sequence number by this delta? Where the delta is the number of bytes added/removed from the stream? Seems easier than reaching into the TCP structure. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."