Date: Fri, 6 May 2011 19:07:59 +0200 From: Cole <cole@opteqint.net> To: freebsd-net@freebsd.org Subject: Re: kernel module, TCP state, and mbuf question Message-ID: <BANLkTi=NXpvTu5WFY9wUdr%2BE4zeUPfJ5Ng@mail.gmail.com> In-Reply-To: <20110506160937.GN90732@funkthat.com> References: <BANLkTin__GBFkT-T90rg8StKeyYEf-vuog@mail.gmail.com> <20110506160937.GN90732@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 May 2011 18:09, John-Mark Gurney <jmg@funkthat.com> wrote: > 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? =A0Where the delta is the number of bytes > added/removed from the stream? > > Seems easier than reaching into the TCP structure. Yeah, that would be me keeping my own state of what the next sequence number should be. I was just wondering how difficult it would be to get to the actual TCP stream state for a given mbuf and to update the next sequence number there if need be. So that is the module is unloaded all the streams will continue to function and it wont kill anything. Regards /Cole
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=NXpvTu5WFY9wUdr%2BE4zeUPfJ5Ng>