From owner-freebsd-net@FreeBSD.ORG  Tue May 17 13:28:01 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 509BF106566B
	for <freebsd-net@freebsd.org>; Tue, 17 May 2011 13:28:01 +0000 (UTC)
	(envelope-from dhartmei@insomnia.benzedrine.cx)
Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch
	[213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9D38FC0C
	for <freebsd-net@freebsd.org>; Tue, 17 May 2011 13:27:59 +0000 (UTC)
Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1])
	by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p4HCmt6u014321
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Tue, 17 May 2011 14:48:55 +0200 (MEST)
Received: (from dhartmei@localhost)
	by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p4HCmtQh011966;
	Tue, 17 May 2011 14:48:55 +0200 (MEST)
Date: Tue, 17 May 2011 14:48:55 +0200
From: Daniel Hartmeier <daniel@benzedrine.cx>
To: Cole <cole@opteqint.net>
Message-ID: <20110517124855.GA25571@insomnia.benzedrine.cx>
References: <BANLkTi=qLfYCA=A5pCSk9OgMCV_9s4zkLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTi=qLfYCA=A5pCSk9OgMCV_9s4zkLg@mail.gmail.com>
User-Agent: Mutt/1.5.12-2006-07-14
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2011 13:28:01 -0000

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