dyoung@pobox.com said:
> > IEEE80211_RADIOTAP_F_FCS flag
> > [...]
> > should be within the outer header
> Outer header?

Well, the header before the variable parts, where one can
just reference an element without decoding more than
necessary.
As said, thare would be room in the it_pad field without
breaking an API, but as I see it adding another element
wouldn't do much damage either.

> > In order to extract the ieee802_11 frame type from a ..._radiotap
> > frame, one needs start offset and length of the payload.
> > [...]
> It shouldn't, and it doesn't.  See the it_len member.

OK, the fixed 64-byte it_len should work with all payload start
alignments if the hardware is not too strange, but there is
no way to express a payload length which is smaller than
the raw mbuf length. The latter would be needed to pass just
the 80211 packet along, without radiotap stuff.

> >    (btw, the DATAPAD field flag should be there too)
> I don't understand.

According to the comment in ieee80211_radiotap.h, the
IEEE80211_RADIOTAP_F_DATAPAD field would tell that there
is a padding between the 802.11 header and the payload.
Again, it should be easy to just extract the payload without
decoding everything else. Not strictly necessary, and forgivable
if there are historical reasons, but I wouldn't do it that
way for a new design.

> There are sensible alignment rules.  All >8-bit fields are aligned on
> their natural boundary.

Hmm -- the order of elements in the structure depends on
the driver/hardware's capabilities, and the actual definitions
all have a __packed__ attached.
And the dissector in "ethereal" really counts bytes, without
considering alignment.

> the documentation is a little sketchy

As most documentation... At least the "ethereal" author(s)
have been trapped.

best regards
Matthias