Re: RFC: 802.11 radio capture header

[David Young <dyoung () pobox com>]

On Tue, Aug 05, 2003 at 11:20:18AM -0700, Guy Harris wrote:
> 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.

  I don't know about that.

> 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".

  Oops. Originally it was an LTV design but I was dissuaded by Sam
  Leffler. I will fix that before I make a new patch.

> 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.

  Right, increasing bit-value order. I will explicitly state it in
  version 0.1. =)

  Note that I screwed up: the "Prism MAC time" bit is not consecutive
  with the other bits. It does not matter, since I do not intend to
  reserve a bit for it any longer.

> 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)?

  I'm glad you mention this, because I wanted to ask you what you thought
  the endianness convention should be for "synthetic" packet headers such
  as this one. Should the endianness be fixed, or should it change with
  the platform? If the former, then the code is slightly more simple;
  if the latter, then cycles are saved.

  My unreasonable reason for putting the TSF timestamp into little-endian
  order is that the TSF timestamp carried by a beacon is little-endian.

> >  #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"?

  You're right. I will do that.

Dave

-- 
David Young             OJC Technologies
dyoung () ojctech com      Urbana, IL * (217) 278-3933
-
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