From owner-freebsd-questions@FreeBSD.ORG Tue Aug 31 02:10:59 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEB6216A4CE for ; Tue, 31 Aug 2004 02:10:59 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86E9B43D41 for ; Tue, 31 Aug 2004 02:10:57 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i7V2AlLF060000; Mon, 30 Aug 2004 21:10:47 -0500 (CDT) (envelope-from dan) Date: Mon, 30 Aug 2004 21:10:47 -0500 From: Dan Nelson To: "Lucas (a.k.a T-Bird or bsdfan3)" Message-ID: <20040831021047.GC33896@dan.emsphone.com> References: <000301c48efa$bfa00500$c022fc18@yourxu5v9frokn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301c48efa$bfa00500$c022fc18@yourxu5v9frokn> X-OS: FreeBSD 5.3-BETA2 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-questions@freebsd.org Subject: Re: Variable length packets? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 02:11:00 -0000 In the last episode (Aug 30), Lucas (a.k.a T-Bird or bsdfan3) said: > I am trying to implement a custom protocol that sends and receives > variable-length packets on top of TCP/IPv4. The problem is that the > length field of the packet is silently being mangled first becoming 0 > and then getting turned into a very large number (about 2-3 billion). > The length field is a u_int32_t and I am using the byteorder > routines. Source code snippets follow: > > --decl of struct packet_t-- > struct packet_t > { > u_int16_t num; > u_int32_t len; > char data[0]; > }; If these are different OSes, the structure may be packed differently. There's almost certainly two bytes of padding between num and len to ensure that len is 32-bit aligned, for example. If you run ktrace on your client (or server), the kdump output will include a hexdump of all data read or written, which might help you determine what's going wrong. -- Dan Nelson dnelson@allantgroup.com