* WiMAX extensions
@ 2007-05-09 6:23 Charles Clancy
[not found] ` <50721.65.74.1.247.1178691838.squirrel-2RFepEojUI1Vf4MZnIYnAze48wsgrGvP@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Charles Clancy @ 2007-05-09 6:23 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
What does the list think about adding WiMAX (IEEE 802.16) fields to the
Radiotap header? While the name is relatively generic, implying any sort
of radio, so far it's very WiFi-centric.
I recently had a pcap DLT allocated for WiMAX+Radiotap, so I'd like the
Radiotap extensions to be relatively universal.
I can put together a list of fields that it would be good to define, if
the list thinks this is an appropriate use for Radiotap.
Thanks!
--
t. charles clancy, ph.d. <> tcc-e45ueOrobK4@public.gmane.org <> www.cs.umd.edu/~clancy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <50721.65.74.1.247.1178691838.squirrel-2RFepEojUI1Vf4MZnIYnAze48wsgrGvP@public.gmane.org>
@ 2007-05-13 3:32 ` David Young
[not found] ` <20070513033218.GL20770-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Young @ 2007-05-13 3:32 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
On Wed, May 09, 2007 at 02:23:58AM -0400, Charles Clancy wrote:
> What does the list think about adding WiMAX (IEEE 802.16) fields to the
> Radiotap header? While the name is relatively generic, implying any sort
> of radio, so far it's very WiFi-centric.
Sounds ok to me.
> I can put together a list of fields that it would be good to define, if
> the list thinks this is an appropriate use for Radiotap.
Yes, please.
Dave
--
David Young OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <20070513033218.GL20770-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
@ 2007-05-28 17:34 ` Charles Clancy
[not found] ` <465B128D.9070904-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Charles Clancy @ 2007-05-28 17:34 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
David Young wrote:
>> I can put together a list of fields that it would be good to define, if
>> the list thinks this is an appropriate use for Radiotap.
>
> Yes, please.
There would certainly be overlap with 802.11. However most
implementations I've seen seem to prefix the fields with IEEE80211_, so
I'd think these would all need to be replicated for 802.16. I'm not
sure the best way to handle it.
In general, 802.16 is much more stateful than 802.11, so much less of
the basic packet/network metadata is available in the headers.
Consequently, there are more things that would be useful to see in the
radiotap header.
Suggested new fields:
- TDD or FDD network
- uplink or downlink
- received frequency (in kHz, MHz is not specific enough)
- BSID (unlike 802.11, this is not in the MAC-CPS)
- whether the PDU contains a CRC32 at the end
- whether the PDU is encrypted
- UIUC or DIUC for the PDU, and associated modulation/coding
--
t. charles clancy, ph.d. <> tcc-e45ueOrobK4@public.gmane.org <> www.cs.umd.edu/~clancy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B128D.9070904-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
@ 2007-05-28 17:41 ` Guy Harris
[not found] ` <465B144F.2070403-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2007-06-27 23:45 ` Guy Harris
1 sibling, 1 reply; 11+ messages in thread
From: Guy Harris @ 2007-05-28 17:41 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
Charles Clancy wrote:
> There would certainly be overlap with 802.11. However most
> implementations I've seen seem to prefix the fields with IEEE80211_, so
> I'd think these would all need to be replicated for 802.16. I'm not
> sure the best way to handle it.
Replicated, or renamed, with the old names kept around for source
compatibility - or with IEEE80211_ and IEEE80216_ names for the same value?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B144F.2070403-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2007-05-28 17:58 ` Charles Clancy
[not found] ` <465B184C.1000306-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 18:00 ` Johannes Berg
1 sibling, 1 reply; 11+ messages in thread
From: Charles Clancy @ 2007-05-28 17:58 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
Guy Harris wrote:
>> There would certainly be overlap with 802.11. However most
>> implementations I've seen seem to prefix the fields with IEEE80211_,
>> so I'd think these would all need to be replicated for 802.16. I'm
>> not sure the best way to handle it.
>
> Replicated, or renamed, with the old names kept around for source
> compatibility - or with IEEE80211_ and IEEE80216_ names for the same value?
Ideally, I'd think renaming fields that apply to any wireless standard
would be best, keeping around the old values for compatibility, of
course. Then there could be protocol-specific fields for each standard.
I think the following would be globally useful:
IEEE80211_RADIOTAP_TSFT
IEEE80211_RADIOTAP_RATE
IEEE80211_RADIOTAP_DB*
IEEE80211_RADIOTAP_ANTENNA
IEEE80211_RADIOTAP_FLAGS (though you might need a general flag set and a
protocol-specific flag set)
Is Radiotap meant to be used on outgoing packets as well? If so, there
are a variety of outgoing packet fields that might also be useful.
--
t. charles clancy, ph.d. <> tcc-e45ueOrobK4@public.gmane.org <> www.cs.umd.edu/~clancy
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B144F.2070403-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2007-05-28 17:58 ` Charles Clancy
@ 2007-05-28 18:00 ` Johannes Berg
1 sibling, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2007-05-28 18:00 UTC (permalink / raw)
To: Guy Harris; +Cc: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
On Mon, 2007-05-28 at 10:41 -0700, Guy Harris wrote:
> Charles Clancy wrote:
>
> > There would certainly be overlap with 802.11. However most
> > implementations I've seen seem to prefix the fields with IEEE80211_, so
> > I'd think these would all need to be replicated for 802.16. I'm not
> > sure the best way to handle it.
>
> Replicated, or renamed, with the old names kept around for source
> compatibility - or with IEEE80211_ and IEEE80216_ names for the same value?
I'd rather see them renamed to something that doesn't carry the 802
number, more use cases might come up.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B184C.1000306-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
@ 2007-05-28 18:01 ` Johannes Berg
2007-05-28 18:15 ` David Young
2007-06-24 5:28 ` David Young
2 siblings, 0 replies; 11+ messages in thread
From: Johannes Berg @ 2007-05-28 18:01 UTC (permalink / raw)
To: Charles Clancy; +Cc: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
[-- Attachment #1: Type: text/plain, Size: 299 bytes --]
On Mon, 2007-05-28 at 13:58 -0400, Charles Clancy wrote:
> Is Radiotap meant to be used on outgoing packets as well? If so, there
> are a variety of outgoing packet fields that might also be useful.
I think it wasn't meant to originally, but in Linux we are going to do
that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B184C.1000306-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 18:01 ` Johannes Berg
@ 2007-05-28 18:15 ` David Young
2007-06-24 5:28 ` David Young
2 siblings, 0 replies; 11+ messages in thread
From: David Young @ 2007-05-28 18:15 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
On Mon, May 28, 2007 at 01:58:36PM -0400, Charles Clancy wrote:
> Guy Harris wrote:
> >>There would certainly be overlap with 802.11. However most
> >>implementations I've seen seem to prefix the fields with IEEE80211_,
> >>so I'd think these would all need to be replicated for 802.16. I'm
> >>not sure the best way to handle it.
> >
> >Replicated, or renamed, with the old names kept around for source
> >compatibility - or with IEEE80211_ and IEEE80216_ names for the same value?
>
> Ideally, I'd think renaming fields that apply to any wireless standard
> would be best, keeping around the old values for compatibility, of
> course. Then there could be protocol-specific fields for each standard.
>
> I think the following would be globally useful:
>
> IEEE80211_RADIOTAP_TSFT
> IEEE80211_RADIOTAP_RATE
> IEEE80211_RADIOTAP_DB*
> IEEE80211_RADIOTAP_ANTENNA
> IEEE80211_RADIOTAP_FLAGS (though you might need a general flag set and a
> protocol-specific flag set)
>
> Is Radiotap meant to be used on outgoing packets as well? If so, there
> are a variety of outgoing packet fields that might also be useful.
I am going to use radiotap for that. I believe someone has already done
it. I have some funding and a plan to add to NetBSD both socket options
and packet ancillary data for sending/receiving packets with radiotap.
I will be bringing proposals to the list in the next few months.
Dave
--
David Young OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933 ext 24
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B184C.1000306-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 18:01 ` Johannes Berg
2007-05-28 18:15 ` David Young
@ 2007-06-24 5:28 ` David Young
2 siblings, 0 replies; 11+ messages in thread
From: David Young @ 2007-06-24 5:28 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
On Mon, May 28, 2007 at 01:58:36PM -0400, Charles Clancy wrote:
> Guy Harris wrote:
> >>There would certainly be overlap with 802.11. However most
> >>implementations I've seen seem to prefix the fields with IEEE80211_,
> >>so I'd think these would all need to be replicated for 802.16. I'm
> >>not sure the best way to handle it.
> >
> >Replicated, or renamed, with the old names kept around for source
> >compatibility - or with IEEE80211_ and IEEE80216_ names for the same value?
>
> Ideally, I'd think renaming fields that apply to any wireless standard
> would be best, keeping around the old values for compatibility, of
> course. Then there could be protocol-specific fields for each standard.
I think that what you mean is, for the fields that WiMax and WiFi
have in common, add a generic alias---e.g., IEEE80211_RADIOTAP_RATE =
RADIOTAP_RATE, but do not assign new presence bits for common fields.
That sounds ok to me.
> I think the following would be globally useful:
>
> IEEE80211_RADIOTAP_TSFT
> IEEE80211_RADIOTAP_RATE
> IEEE80211_RADIOTAP_DB*
> IEEE80211_RADIOTAP_ANTENNA
All of those fields have specific definitions. Do they apply equally
well to WiMax?
> IEEE80211_RADIOTAP_FLAGS (though you might need a general flag set and a
> protocol-specific flag set)
Sure. The flags have almost run out, though. :-)
Dave
--
David Young OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933 ext 24
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <465B128D.9070904-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 17:41 ` Guy Harris
@ 2007-06-27 23:45 ` Guy Harris
[not found] ` <2A4D4978-D308-40EA-89D5-A2304A5947C7-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
1 sibling, 1 reply; 11+ messages in thread
From: Guy Harris @ 2007-06-27 23:45 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
On May 28, 2007, at 10:34 AM, Charles Clancy wrote:
> Suggested new fields:
...
> - received frequency (in kHz, MHz is not specific enough)
So that'd be an alternative to IEEE80211_RADIOTAP_CHANNEL and
IEEE80211_RADIOTAP_XCHANNEL, both of which give the frequency in MHz?
(BTW, the current FreeBSD ieee80211_radiotap.h defines
IEEE80211_RADIOTAP_XCHANNEL as 14 and the current NetBSD
ieee80211_radiotap.h defines IEEE80211_RADIOTAP_RX_FLAGS as 14.
Hopefully one or the other of those is *NOT* currently being used, as
that means that tcpdump, Wireshark, etc. can't handle a property with
a code of 14 *AND*, at least as I understand the way radiotap works,
can't handle anything after 14, either, as they don't know how long
that property is. NetBSD and OpenBSD also collide on the value of 14,
as well as values after it.)
> - whether the PDU contains a CRC32 at the end
There's already a flag for that in the IEEE80211_RADIOTAP_FLAGS field
- IEEE80211_RADIOTAP_F_FCS.
> - whether the PDU is encrypted
There's a IEEE80211_RADIOTAP_F_WEP flag; should that become a "send
with encryption" flag? (What about WPA?)
Does "encrypted" here mean whether the frame contents are encrypted as
delivered to the application, or whether the frame was encrypted when
sent on the air? (For 802.11, I think there are some cases where the
adapter+driver deliver decrypted frames with the "encrypted" bit set
in the header, which is why Wireshark has an option to ignore that bit.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WiMAX extensions
[not found] ` <2A4D4978-D308-40EA-89D5-A2304A5947C7-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2007-06-28 1:10 ` David Young
0 siblings, 0 replies; 11+ messages in thread
From: David Young @ 2007-06-28 1:10 UTC (permalink / raw)
To: radiotap-rN9S6JXhQ+WXmMXjJBpWqg
On Wed, Jun 27, 2007 at 04:45:04PM -0700, Guy Harris wrote:
>
> On May 28, 2007, at 10:34 AM, Charles Clancy wrote:
>
> >Suggested new fields:
>
> ...
>
> >- received frequency (in kHz, MHz is not specific enough)
>
> So that'd be an alternative to IEEE80211_RADIOTAP_CHANNEL and
> IEEE80211_RADIOTAP_XCHANNEL, both of which give the frequency in MHz?
>
> (BTW, the current FreeBSD ieee80211_radiotap.h defines
> IEEE80211_RADIOTAP_XCHANNEL as 14 and the current NetBSD
> ieee80211_radiotap.h defines IEEE80211_RADIOTAP_RX_FLAGS as 14.
> Hopefully one or the other of those is *NOT* currently being used, as
> that means that tcpdump, Wireshark, etc. can't handle a property with
> a code of 14 *AND*, at least as I understand the way radiotap works,
> can't handle anything after 14, either, as they don't know how long
> that property is. NetBSD and OpenBSD also collide on the value of 14,
> as well as values after it.)
Guy, your understanding is correct. The divergence is not good for
anyone. The responsible people in OpenBSD and FreeBSD should bring
proposals to the list in order to get presence bits assigned.
Dave
--
David Young OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org Urbana, IL * (217) 278-3933 ext 24
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-06-28 1:10 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-09 6:23 WiMAX extensions Charles Clancy
[not found] ` <50721.65.74.1.247.1178691838.squirrel-2RFepEojUI1Vf4MZnIYnAze48wsgrGvP@public.gmane.org>
2007-05-13 3:32 ` David Young
[not found] ` <20070513033218.GL20770-eZ+MEZF6i8Dc+919tysfdA@public.gmane.org>
2007-05-28 17:34 ` Charles Clancy
[not found] ` <465B128D.9070904-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 17:41 ` Guy Harris
[not found] ` <465B144F.2070403-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2007-05-28 17:58 ` Charles Clancy
[not found] ` <465B184C.1000306-VX+DGZyGJwM3uPMLIKxrzw@public.gmane.org>
2007-05-28 18:01 ` Johannes Berg
2007-05-28 18:15 ` David Young
2007-06-24 5:28 ` David Young
2007-05-28 18:00 ` Johannes Berg
2007-06-27 23:45 ` Guy Harris
[not found] ` <2A4D4978-D308-40EA-89D5-A2304A5947C7-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2007-06-28 1:10 ` David Young
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).