Hi -
trying to narrow down why the ral/ural driver in NetBSD doesn't
want to connect to the Cabletron nor the Cisco AP I have in reach
I've found sone design problems with the "radiotap" bpf frame format.
It got appearant that "ethereal" complained about a lot of
"malformed packets" when I captured through "ral0" with the _radio
link type.

The reason is appearently that the packets captured have the FCS
appended and that BPF clients don't get told about this.
The intended way to deal with this seems to be to set the
IEEE80211_RADIOTAP_F_FCS flag within the variable length tail
of the radiotap header. (ethereal doesn't deal with this yet)

While that bit is easily added, I found that the place where
it appears is too much buried within data structures to be useful.
It should be within the outer header.
In order to extract the ieee802_11 frame type from a ..._radiotap
frame, one needs start offset and length of the payload. That
shouldn't need a lot of parsing through variable length header
structures. Whet makes it worse is that all the _radiotap
header stuff consists of __packed__ variable length elements. In
theory, drivers shouldn't access the elements directly (the >8bit
elements of course).

The _radiotap link later type isn't widely used yet, so I'd
propose to correct for these problems as soon as possible.

I'm proposing:
1. Put the flags which affect the coarse layout of the captured
   packet into the header. Eg into the it_pad field, or add a new
   "capture_flag" or so member.
   (btw, the DATAPAD field flag should be there too)
2. Define some sensible alignment rules for the remaining variable
   length part of the radiotap header. So that drivers can just
   fill in values on packat receive without worrying about
   unaligned accesses.

best regards
Matthias