Date: Tue, 31 Aug 2004 06:29:52 -0500 From: "Lucas (a.k.a T-Bird or bsdfan3)" <tbird-contact@cox.net> To: "Dan Nelson" <dnelson@allantgroup.com> Cc: freebsd-questions@freebsd.org Subject: Re: Variable length packets? Message-ID: <000f01c48f4d$d583b990$c022fc18@yourxu5v9frokn> References: <000301c48efa$bfa00500$c022fc18@yourxu5v9frokn> <20040831021047.GC33896@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll try using __attribute__ ((packed)) on the declaration of struct
packet_t.
----- Original Message -----
From: "Dan Nelson" <dnelson@allantgroup.com>
To: "Lucas (a.k.a T-Bird or bsdfan3)" <tbird-contact@cox.net>
Cc: <freebsd-questions@freebsd.org>
Sent: Monday, August 30, 2004 9:10 PM
Subject: Re: Variable length packets?
> 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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000f01c48f4d$d583b990$c022fc18>
