From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 15:27:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3F0716A420 for ; Tue, 7 Jun 2005 15:27:40 +0000 (GMT) (envelope-from christian@kuhtz.com) Received: from athenaeum.kuhtz.com (athenaeum.kuhtz.com [68.16.106.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F05743D5E for ; Tue, 7 Jun 2005 15:27:40 +0000 (GMT) (envelope-from christian@kuhtz.com) Received: by athenaeum.kuhtz.com (Postfix, from userid 507) id 0558290C013; Tue, 7 Jun 2005 11:27:39 -0400 (EDT) Received: from [192.168.100.233] (sntlabfw [205.152.56.163]) by athenaeum.kuhtz.com (Postfix) with ESMTP id BD6BA90C00C for ; Tue, 7 Jun 2005 11:27:38 -0400 (EDT) Message-ID: <42A5BCEB.8020109@kuhtz.com> Date: Tue, 07 Jun 2005 11:27:39 -0400 From: Christian Kuhtz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on athenaeum.kuhtz.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=4.9 tests=AWL autolearn=ham version=3.0.3 Subject: divert sock api q 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, 07 Jun 2005 15:27:41 -0000 Hello, I'm using the DIVERT socket API for a proof of concept lab setup here, and I could use some help.. Two boxes are involved, packets traverse both in series. The first one, lets call her A, is taking the UDP packet off the wire, inserts a few bytes after the UDP header, and sticks it back on the wire. The second machine, lets call her B, grabs the packet as it comes in, strips the bytes we inserted, and sticks it back on the wire. Or so goes the theory. What I'm running into is the following.. When I sendto() the modified frame on A, the size is correctly reported as what the frame was modified to be. When the frame arrives on B, I only recvfrom() as many bytes as the virgin packet used to be when it entered A prior to the modification. Anyone have any idea what's going on here and how to fix this length mismatch? I thought the API updates the length when the frame is sent, and sendto() does report the correct length.. I apologize for being so exceptionally dense, this is driving me completely up the walls.. Regards, Christian