Subject: Re: issues with 802.11 radiotap
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: David Young <firstname.lastname@example.org>
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.
> 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
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.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933