Re: TSFT
Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/[email protected]> Sat, 17 Nov 2012 10:56:24 -0800
| Newsgroups | org.netbsd.radiotap |
|---|---|
| Message-ID | <[email protected]> |
On Nov 17, 2012, at 9:46 AM, David Young <[email protected]> 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.