Re: use of radiotap bit 14?

Johannes Berg <[email protected]> Thu, 19 Jun 2008 21:10:33 +0200
Newsgroups	org.netbsd.radiotap
Message-ID	<[email protected]>
On Thu, 2008-06-19 at 13:56 -0500, David Young wrote:

> I favor these assignments:
> 
> 14 /RX flags
> 15 /TX flags
> 16 /RTS retries
> 17 /data retries
> 18 /XChannel 

That'd be great to me. Want me to declare them that on the wiki, move
them over to the defined-fields and add the other ones as "suggested
fields" without assigned numbers?

> I think that what you mean is to lead a discussion of fields 14 and
> beyond?  I reckon that no fewer than 4 persons or organizations have
> "taken over" maintainership of the standard by now, and that is how we got
> into the current mess, with the same bits used for different purposes. :-)
> 
> I initiated the mailing list so that there is one place to propose new
> fields for discussion and adoption by the community of radiotap users.
> It's not here so that anybody, least of all you and I, can tell everybody
> else what the fields are.

Yeah, I know, it's a mess and will always be unless we discuss things
here and on the wiki.

> I don't think that reaching agreement on fields 14 and greater is
> necessarily so hard.  Here are three reasons why.
> 
> First, Guy Harris invited a lot of people to this discussion list who
> seemed to have a stake in radiotap, and some of them did not show up.
> As I said before, we do not have to act as advocates for people who don't
> show up.  If the person who uses bit 14 for the flavor of packets will
> not stand up for it here, then there is no use wringing our hands over
> the conflicting assignment.
> 
> Agreement is in everybody's interest.  Disagreement is not.
> 
> This is not the IETF, but I think that "rough consensus and running
> code" is a perfectly fine way to decide what fields we adopt, and there
> is neither a consensus nor running code for some fields.  I think that
> the lack of code makes the current "conflicts" easy to resolve: just how
> much pain can we cause by assigning field 15 to Rx flags if some obscure
> driver emits field 15 equal to a packet's smell, but neither WireShark
> nor TCPDump interprets it at all?

True.

Problem is, wireshark actually takes bit 14 to mean "FCS in header".
Easily changed though if Gerald is willing to take such a patch, I can
cook up a patch to make it parse the fields above.

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