Re: [RFA] RX flags

Johannes Berg <[email protected]> Tue, 08 Jul 2008 11:51:57 +0200
Newsgroups	org.netbsd.radiotap
Message-ID	<[email protected]>
On Mon, 2008-07-07 at 13:12 -0500, David Young wrote:
> On Thu, Jun 26, 2008 at 01:14:50PM +0200, Johannes Berg wrote:
> > This is a request for adoption of the following new radiotap features:
> > 
> >  * a new flag in the "flags" field (field 1):
> >     - short guard interval
> >  * the new "RX flags" field (field 14), currently containing the
> >    following flag:
> > ???    - bad FCS
> 
> >     - bad PLCP
> 
> Thanks for bringing this proposal.  I agree with it, for one.  I have
> a few clarifying questions.
> 
> Just to be clear, perhaps cite the IEEE specs where they define FCS and
> short GI.  Implementors will want to know, is FCS failure different
> than ICV failure?  Presumably, by "bad PLCP," PLCP CRC check failure
> is intended.

Short GI isn't actually defined yet, it's part of 802.11n. Did I say
antything about ICV failures? As for PLCP, yes, there's a checksum in
it, but I think there are also other ways it can be invalid. I'll look
it up and add some documentation.

> > I propose to make changes to radiotap as follows [1]:
> > 
> >  1) Reserve bit number 6 (mask 0x40) of the flags field (field 1)
> >     because it was used by some implementations (wireshark) as "bad FCS"
> 
> Pleas excuse my forgetfulness. :-) Is there a conflict with "bad FCS"
> at bit 6 field 1?  Is there representation for the conflict on the list?

I might not have posted that, sorry. Basically, bit 6 in field 1 is used
by wireshark for "bad FCS".

> If not, I may bring a second proposal to assign bit 6 for bad FCS,
> the rationale being that the bit is already used in that way, and some
> implementations may avoid including an Rx flags field by using bit 6
> field 1.

There's no actual conflict, but I'm trying to avoid a situation where
"standard" radiotap has _two_ bits meaning the same thing, one in the RX
flags and one in the field 1 flags. Since the RX flags one seems to be
more used, I opted for using that one and reserving the other one.

I did consider using bit 6 field 1 for "bad FCS" for precisely that
reason (no need to add RX flags) but that would mean even those
generators currently generating "RX flags" in bit 14 would have to be
changed. I don't have a problem with that per se, but I fear that it may
lead to confusion.

johannes
signature.asc (application/pgp-signature, 836 B)