From: David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Scott Raynel
<scottraynel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
radiotap-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org
Subject: Re: RFC: radiotap discrepancy in Linux vs OpenBSD
Date: Sun, 25 Mar 2007 22:38:39 -0500 [thread overview]
Message-ID: <20070326033839.GA24097__10646.4659948417$1216696499$gmane$org@che.ojctech.com> (raw)
In-Reply-To: <20070325232416.64xwkc0kw04oosg0-2RFepEojUI3Rd1RZctBqVdHuzzzSOjJt@public.gmane.org>
On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote:
> Hello!
(Oops, this time cc'd radiotap.)
The place to discuss this is the mailing list
radiotap-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org, 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-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933
next parent reply other threads:[~2007-03-26 3:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070325232416.64xwkc0kw04oosg0@webmail.spamcop.net>
[not found] ` <20070325232416.64xwkc0kw04oosg0-2RFepEojUI3Rd1RZctBqVdHuzzzSOjJt@public.gmane.org>
2007-03-26 3:38 ` David Young [this message]
[not found] ` <20070326033839.GA24097@che.ojctech.com>
[not found] ` <20070326033839.GA24097-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
2007-03-26 15:41 ` RFC: radiotap discrepancy in Linux vs OpenBSD Luis R. Rodriguez
[not found] ` <43e72e890703260841v56047559y90b7c25c9c458564@mail.gmail.com>
[not found] ` <43e72e890703260841v56047559y90b7c25c9c458564-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-03-26 16:59 ` David Young
[not found] ` <20070326033729.GG31621@che.ojctech.com>
[not found] ` <20070326033729.GG31621-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
2007-03-26 22:45 ` Pavel Roskin
[not found] ` <1174949149.28132.49.camel@dv>
2007-03-28 18:04 ` Marcelo Tosatti
[not found] ` <20070328180413.GC17793@dmt>
2007-03-28 20:33 ` Pavel Roskin
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='20070326033839.GA24097__10646.4659948417$1216696499$gmane$org@che.ojctech.com' \
--to=dyoung-e+axbwqsrlaavxtiumwx3w@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=proski-mXXj517/zsQ@public.gmane.org \
--cc=radiotap-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org \
--cc=scottraynel-Re5JQEeQqe8AvxtiuMwx3w@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).