David Young wrote:
> On Mon, Jul 11, 2005 at 10:09:47PM +0200, Matthias Drochner wrote:
> 
>>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)

I think you're using an old version of ethereal; I've been able to set a 
config option through the GUI to indicate rx'd frames have FCS (or maybe 
it's may have FCS).  OTOH it would be good for tools to honor the 
radiotap flag so naive users didn't need to know to do this.

>>
>>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.
> 
> 
> Outer header?
> 

He's referring to the fixed length field at the front of radiotap data.

> 
>>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.
> 
> 
> It shouldn't, and it doesn't.  See the it_len member.
> 
> 
>>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.

Actually this is not true; it's rather widely used and the latest 
libpcap even knows how to build bpf programs to do in-kernel filtering.

>>
>>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)
> 
> 
> I don't understand.

radiotap consumers need to parse the flags and honor FCS and DATAPAD. 
I've been meaning to send patches to the libpcap/tcpdump folks to do 
that.  It's not hard (I've done it at least once already for kismet I 
think) and doesn't require putting the flags in the front.

> 
> 
>>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.
> 
> 
> There are sensible alignment rules.  All >8-bit fields are aligned on
> their natural boundary.
> 
> Maybe you have not understood how radiotap works.  I think the design
> addresses your concerns, and then some.  This may be my fault; the
> documentation is a little sketchy.  BTW, I believe I added a radiotap
> manual page from FreeBSD to -current, but it is not installed.

There may be some multi-byte data that need byte swapping but I believe 
the way things are defined most everything is/can be precalculated or is 
in network byte order so can be copied directly.  The point being that 
the overhead is minimal in the fast path.

	Sam