From: David Young <dyoung@pobox.com>
To: Pavel Roskin <proski@gnu.org>
Cc: linux-wireless@vger.kernel.org, Scott Raynel <scottraynel@gmail.com>
Subject: Re: RFC: radiotap discrepancy in Linux vs OpenBSD
Date: Sun, 25 Mar 2007 22:37:29 -0500 [thread overview]
Message-ID: <20070326033729.GG31621@che.ojctech.com> (raw)
In-Reply-To: <20070325232416.64xwkc0kw04oosg0@webmail.spamcop.net>
On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote:
> Hello!
The place to discuss this is the mailing list
radiotap@ojctech.com, which I have cc'd. Subscribe at
<http://mail.ojctech.com/mailman/listinfo/radiotap>. Please feel free
to circulate the URL.
> I have noticed two different incompatible changes to enum
> ieee80211_radiotap_type in ieee80211_radiotap.h.
>
> One is found in the current wireless-2.6.git:
>
> IEEE80211_RADIOTAP_RX_FLAGS = 14,
> IEEE80211_RADIOTAP_TX_FLAGS = 15,
> IEEE80211_RADIOTAP_RTS_RETRIES = 16,
> IEEE80211_RADIOTAP_DATA_RETRIES = 17,
These fields are slated to become part of the standard, I just haven't got
around to updating the manual page, yet. I have time to do that tonight.
> It was added together with Marvell Libertas USB driver.
> Another set of the flags can be found in CVS OpenBSD:
>
> IEEE80211_RADIOTAP_FCS = 14,
> IEEE80211_RADIOTAP_HWQUEUE = 15,
> IEEE80211_RADIOTAP_RSSI = 16,
These fields are not part of the standard, and they will not become part
of the standard with these numbers. This is the first time I have ever
heard of HWQUEUE and RSSI, actually. What are they for?
> I think Marvell developers could act gracefully and push the flags it introduces
> to higher numbers. Doing something like that on the OpenBSD side would be
> harder. I would also like to see joining Rx and Tx flags into one 32-bit
> value.
> But we need some coordination when new fields are added to the protocol.
Right. People must coordinate on the radiotap list.
> Uncalibrated RSSI may also be a candidate for
> the driver-specific data if OpenBSD can be persuaded to abandon its present
> number.
OpenBSD will need to abandon its present numbers in order to stay
compatible with tcpdump and wireshark.
> It's important that presence of driver specific fields doesn't break parsing of
> the standard fields, even if new fields are made standard. I think driver
> specific flags don't belong to the it_present bitmap, but should go to the
> beginning of the driver specific area.
You are right that the driver-specific fields cannot go in the bitmap.
Dave
--
David Young OJC Technologies
dyoung@ojctech.com Urbana, IL * (217) 278-3933
next prev parent reply other threads:[~2007-03-26 4:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 3:24 RFC: radiotap discrepancy in Linux vs OpenBSD Pavel Roskin
2007-03-26 3:37 ` David Young [this message]
2007-03-26 22:45 ` Pavel Roskin
2007-03-28 18:04 ` [Radiotap] " Marcelo Tosatti
2007-03-28 20:33 ` Pavel Roskin
2007-03-26 3:38 ` David Young
2007-03-26 15:41 ` Luis R. Rodriguez
2007-03-26 16:59 ` David Young
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=20070326033729.GG31621@che.ojctech.com \
--to=dyoung@pobox.com \
--cc=linux-wireless@vger.kernel.org \
--cc=proski@gnu.org \
--cc=scottraynel@gmail.com \
/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 NNTP newsgroup(s).