Skip site navigation (1)Skip section navigation (2)
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>