WiMAX extensions

WiMAX extensions

[Charles Clancy]

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

Re: WiMAX extensions

[David Young]

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

Re: WiMAX extensions

[Charles Clancy]

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

Re: WiMAX extensions

[Guy Harris]

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?

Re: WiMAX extensions

[Charles Clancy]

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

Re: WiMAX extensions

[Johannes Berg]

[-- 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 --]

Re: WiMAX extensions

[Johannes Berg]

[-- 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 --]

Re: WiMAX extensions

[David Young]

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

Re: WiMAX extensions

[David Young]

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

Re: WiMAX extensions

[Guy Harris]

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.)

Re: WiMAX extensions

[David Young]

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