Re: TSFT

[Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]

On Nov 17, 2012, at 9:46 AM, David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote:

> Wireshark doesn't already have more than two "interpretation modes" for
> radiotap headers, does it?  That would be too bad.  I realize that there
> may be already be a mode for a particular OS....

That's the only preference setting Wireshark's radiotap dissection code has.

The OS in question is OpenBSD, as per

	http://www.radiotap.org/rejected-fields/FCS%20in%20header

OpenBSD's other collisions are 15 for hardware queue:

	http://www.radiotap.org/suggested-fields/hardware%20queue

rather than TX flags:

	http://www.radiotap.org/suggested-fields/TX%20flags

and RSSI:

	http://www.radiotap.org/suggested-fields/RSSI

rather than RTS retries:

	http://www.radiotap.org/suggested-fields/RTS%20retries

but the latter two are suggested fields rather than defined fields.

We could, I guess, define a "standard radiotap" link-layer type header value, and have dissectors that look at flags above 13 always handle those in the standard fashion and have programs that process radiotap headers in files either have a preference to control how to interpret the existing radiotap link-layer header type or just wire in one of the choices.  I don't know whether that's worth the effort.