Re: RFC: 802.11 radio capture header

[Guy Harris <guy () alum mit edu>]

On Sat, Aug 02, 2003 at 05:11:49PM -0500, David Young wrote:
> I have attached the header file (ieee802_11_radio.h) defining an improved
> (IMHO) generic 802.11 radio capture format. I have also attached patches
> containing my implementation for tcpdump. Please consider this format
> for adoption by tcpdump.

It requires 64-bit integer support; are there any compilers of interest
that don't support 64-bit integers?  If not, we might want to use 64-bit
integers in the NFS dissector as well.

Not all platforms necessarily define int64_t and u_int64_t;

        AC_LBL_CHECK_TYPE(int64_t, long long)
        AC_LBL_CHECK_TYPE(u_int64_t, unsigned long long)

would have t be added to configure.in (I'm assuming here that all UNIX
compilers that support 64-bit integral types allow "long long" and
"unsigned long long" to be used for them); for compiling with MSVC++,
a typedef of those to __int64 or whatever MSVC++ uses would be required.

The header file speaks of "LTVs", but the items don't actually appear to
carry a type or length value with them.  It should probably call them
something else, unless "LTV" doesn't stand for "length/type/value".

I infer - although it should perhaps be explicitly stated - that items
must appear in increasing bit-value order, so that, as new items are
added, their data appears at the end, so that old parsers would just
stop when after checking and processing the last item they know about,
and don't have to know how to skip unknown values.

> +#define EXTRACT_LE_64BITS(p) \
> +     ((u_int64_t)((u_int64_t)*((const u_int8_t *)(p) + 7) << 56 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 6) << 48 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 5) << 40 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 4) << 32 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 3) << 24 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 2) << 16 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 1) << 8 | \
> +                  (u_int64_t)*((const u_int8_t *)(p) + 0)))

Not all platforms that support 802.11 are little-endian; in fact, I work
for a company whose big-endian machines support it.  (802.11 interfaces
currently show up as Ethernet interfaces to BPF in Mac OS X, but in case
we ever change that - DISCLAIMER: I don't speak for Apple, and am not
saying it will change, or won't change, or saying whether we're thinking
of changing it - should the byte-order be forced to little-endian, or
should it be the byte order of the capture file (which leaves room for
screwups, although hopefully nobody *will* screw up by writing code that
produces X-endian capture files with Y-endian 802.11 information)?

>  #include "ieee802_11.h"
> +#ifdef HAVE_IEEE80211RADIOTAP_H
> +#include <net/if_ieee80211radiotap.h>
> +#else
> +#include "ieee802_11_radio.h"
> +#endif

Those have to be kept in sync anyway, so why not just always include
"ieee802_11_radio.h"?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe