Re: use of radiotap bit 14?

[David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

On Fri, Aug 31, 2007 at 12:16:54AM +0200, Johannes Berg wrote:
> Our radiotap header in Linux defines bit 14 as
> IEEE80211_RADIOTAP_RX_FLAGS; however running wireshark on it tells me
> that this bit means "FCS in header". Does anybody know which use is
> correct, if any?
> 
> Maybe we should simply skip to bit 32 or something and start redefining
> things properly?

There are technical reasons that we cannot simply skip.  I have a couple
of technical solutions in mind.

Solution 1: introduce a new bit, m, that nobody has used so far.
        Let it stand for the presence of a 32-bit magic number.
        When an interpreter sees a header whose presence bit 14 is
        set, let it test presence bit m.  If m is not present, let the
        interpreter abort.  If m is present, let the interpreter skip
        forward until it finds the magic at a 32-bit boundary.  Let it
        continue processing presence bits > m in the usual way.

Solution 2: increase the radiotap version number, and start over from
        bit 0.  Now we need a "legacy" parser for v0, 0 <= bit <= 13,
        and a "next gen" parser for v1.  No v0 header with bits >=
        14 set can be interpreted without ambiguity.

        2a: adopt all of the legacy presence bits 0 through 13 in v1
        2b: adopt some of the legacy presence bits in v1
        2c: start from scratch for v1

We could also use both Solution 1 and Solution 2; let interpreters treat
every v0 bit >= 14 as vendor-specific.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24