From owner-freebsd-net@FreeBSD.ORG Tue May 17 13:16:52 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 64F59106564A for ; Tue, 17 May 2011 13:16:52 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5D98FC0A for ; Tue, 17 May 2011 13:16:51 +0000 (UTC) Received: by iwn33 with SMTP id 33so558425iwn.13 for ; Tue, 17 May 2011 06:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.209 with SMTP id fz17mr407940ibb.140.1305638211503; Tue, 17 May 2011 06:16:51 -0700 (PDT) Received: by 10.231.14.2 with HTTP; Tue, 17 May 2011 06:16:51 -0700 (PDT) X-Originating-IP: [196.215.107.196] In-Reply-To: <20110517124855.GA25571@insomnia.benzedrine.cx> References: <20110517124855.GA25571@insomnia.benzedrine.cx> Date: Tue, 17 May 2011 15:16:51 +0200 Message-ID: From: Cole To: Daniel Hartmeier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Kern Mod and TCP retrasmit problem 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: Tue, 17 May 2011 13:16:52 -0000 Hi. These are obviously things I will need to look into regarding retransmission if the packet does actually get lost. As for the MTU issue, if the kernel mod pushes the data over the MTU size, then the packet is not changed and left as is. I was hoping to keep this clean, and use existing methods for hooking into the stream. Also the goal im working for is to be able to use this on a box doing routing to hopefully get some sort of compression working between 2 end points. So most of the data would not actual be generated from userland processes. So im back to the original issue of trying to track down the variable/structure that is holding the original size of the packet or some variable holding the expected return ACK? Thanks /Cole On 17 May 2011 14:48, Daniel Hartmeier wrote: > What if your modified (shortened) packet does get lost? If you > messed with the tcpcb in the way you intend, how do you plan on > getting retransmission working, when it's needed? > > Or what if you enlarge a packet, are you sure it won't violate > the MTU? > > It seems you're doing this on wrong side of the stack. Why don't > you hook your code into the side facing userland, where socket > writes from the userland process add data to the kernel buffer, > and the socket is still a stream? > > Or what's the reason for doing it after the stream has been > packetized already? > > Daniel >