* Assigning a new DLT_ value for "standardized" radiotap? @ 2010-02-17 2:08 Guy Harris [not found] ` <5F21AFA5-4D4C-49A0-A228-A1177630E366-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Guy Harris @ 2010-02-17 2:08 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw The presence-bit-number collisions mentioned on the radiotap Web site appear to be due to OpenBSD doing its own thing: 14: FCS in OpenBSD, RX Flags in the standard and assigned for that in NetBSD and Linux 15: hardware queue in OpenBSD, proposed for TX flags in the standard and assigned for that in NetBSD and Linux 16: RSSI in OpenBSD, proposed for RTS Retries in the standard and assigned for that in NetBSD and Linux (There was also a brief period of time, between 2007-06-11 and 2007-07-01, where FreeBSD used 14 for the extended channel information, but it got moved to 18; it appears that was done before FreeBSD 7.0 got released, so it doesn't appear that any *released* version used 14 for the extended channel information.) I've filed an bug against this: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=5691 but nothing has been done for it; I've also asked Reyk Floeter about it, and heard nothing. I forget whether I've asked Damien Bergamini about it or not. Unfortunately, there are probably both OpenBSD and NetBSD/Linux captures out there with a network type value of 127, so we can't easily make tcpdump or Wireshark or... handle both automatically (a command-line flag for tcpdump and a preference for Wireshark could be used). If we were to introduce a new DLT_ value for "standard radiotap", tcpdump and Wireshark could unconditionally interpret those presence bit values as having the NetBSD/Linux meaning, and use a flag/preference or whatever for the existing value (or just blow off OpenBSD). Would that be useful? ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <5F21AFA5-4D4C-49A0-A228-A1177630E366-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]
* Re: Assigning a new DLT_ value for "standardized" radiotap? [not found] ` <5F21AFA5-4D4C-49A0-A228-A1177630E366-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> @ 2010-02-17 8:27 ` Johannes Berg [not found] ` <1266395272.4006.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Johannes Berg @ 2010-02-17 8:27 UTC (permalink / raw) To: Guy Harris; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw [-- Attachment #1: Type: text/plain, Size: 368 bytes --] On Tue, 2010-02-16 at 18:08 -0800, Guy Harris wrote: > The presence-bit-number collisions mentioned on the radiotap Web site > appear to be due to OpenBSD doing its own thing: > > 14: FCS in OpenBSD, RX Flags in the standard and assigned for that in > NetBSD and Linux Didn't I go and add a preferences setting to wireshark for this collision? johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <1266395272.4006.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: Assigning a new DLT_ value for "standardized" radiotap? [not found] ` <1266395272.4006.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2010-02-17 8:38 ` Gábor Stefanik [not found] ` <69e28c911002170038q2a401120l369b5dffaa016e01-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 4+ messages in thread From: Gábor Stefanik @ 2010-02-17 8:38 UTC (permalink / raw) To: Johannes Berg; +Cc: Guy Harris, radiotap-sUITvd46vNxg9hUCZPvPmw On Wed, Feb 17, 2010 at 9:27 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote: > On Tue, 2010-02-16 at 18:08 -0800, Guy Harris wrote: >> The presence-bit-number collisions mentioned on the radiotap Web site >> appear to be due to OpenBSD doing its own thing: >> >> 14: FCS in OpenBSD, RX Flags in the standard and assigned for that in >> NetBSD and Linux > > Didn't I go and add a preferences setting to wireshark for this > collision? > > johannes > Yes, but Guy is talking about auto-detection. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <69e28c911002170038q2a401120l369b5dffaa016e01-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Assigning a new DLT_ value for "standardized" radiotap? [not found] ` <69e28c911002170038q2a401120l369b5dffaa016e01-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-02-17 18:49 ` Guy Harris 0 siblings, 0 replies; 4+ messages in thread From: Guy Harris @ 2010-02-17 18:49 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw On Feb 17, 2010, at 12:38 AM, Gábor Stefanik wrote: > Yes, but Guy is talking about auto-detection. Or, at least, semi-automatic - the preference would be ignored for the new DLT_ value, as those captures always use the standard presence bit values; it would be needed only for the old DLT_ value. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-02-17 18:49 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-17 2:08 Assigning a new DLT_ value for "standardized" radiotap? Guy Harris [not found] ` <5F21AFA5-4D4C-49A0-A228-A1177630E366-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 2010-02-17 8:27 ` Johannes Berg [not found] ` <1266395272.4006.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2010-02-17 8:38 ` Gábor Stefanik [not found] ` <69e28c911002170038q2a401120l369b5dffaa016e01-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-02-17 18:49 ` Guy Harris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).