From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
To: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org
Subject: Assigning a new DLT_ value for "standardized" radiotap?
Date: Tue, 16 Feb 2010 18:08:15 -0800 [thread overview]
Message-ID: <5F21AFA5-4D4C-49A0-A228-A1177630E366@alum.mit.edu> (raw)
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?
next reply other threads:[~2010-02-17 2:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-17 2:08 Guy Harris [this message]
[not found] ` <5F21AFA5-4D4C-49A0-A228-A1177630E366-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2010-02-17 8:27 ` Assigning a new DLT_ value for "standardized" radiotap? 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5F21AFA5-4D4C-49A0-A228-A1177630E366@alum.mit.edu \
--to=guy-frubxkncsvf2fbvcvol8/a@public.gmane.org \
--cc=radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).