Subject: Re: issues with 802.11 radiotap
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: David Young <dyoung@pobox.com>
List: tech-net
Date: 07/11/2005 15:42:33
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)
> 
> 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?

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

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

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933