RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Correct radiotap header for 802.11ad
@ 2015-08-22 19:41 Richard Sharpe
       [not found] ` <CACyXjPzq-ePB1ux6wi_Rv3onPKXomcJcm15XJwA51u0E4W2txw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Sharpe @ 2015-08-22 19:41 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A

Hi folks,

I have some 802.11ad captures because of some fixes to the Wireshark
802.11 dissector I am looking at doing.

One thing I notice is that the radiotap header contains both a Channel field
and an MCS field.

The Present flags say that Flags are present, Channel is present and
HT Information is present.

The channel frequency is 60480MHz which seems to be reasonable.

The MCS field says that the MCS index is present and that index is 0.

It seems to me that this last field is perhaps incorrect, because the
radiotap information dissector claims that the PHY type is 802.11n,
and that seems to come about because the radiotap header use the MCS
index info to claim that the PHY type was 802.11n.

Should I be letting the capture hardware vendor know that they are
generating the wrong info?

I probably should also have some override stuff in the radiotap
dissector that uses the frequency field to correctly set the PHY type.

Any comments?

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found] ` <CACyXjPzq-ePB1ux6wi_Rv3onPKXomcJcm15XJwA51u0E4W2txw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-08-22 20:59   ` Guy Harris
       [not found]     ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Guy Harris @ 2015-08-22 20:59 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A


On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I have some 802.11ad captures because of some fixes to the Wireshark
> 802.11 dissector I am looking at doing.
> 
> One thing I notice is that the radiotap header contains both a Channel field
> and an MCS field.

That is to be expected for 11n packets.

> The Present flags say that Flags are present, Channel is present and
> HT Information is present.

By "HT Information" do you mean "the MCS field"?

The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.

> The channel frequency is 60480MHz which seems to be reasonable.
> 
> The MCS field says that the MCS index is present and that index is 0.
> 
> It seems to me that this last field is perhaps incorrect, because the
> radiotap information dissector claims that the PHY type is 802.11n,
> and that seems to come about because the radiotap header use the MCS
> index info to claim that the PHY type was 802.11n.

Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.

From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:

	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.

which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.

> Should I be letting the capture hardware vendor know that they are
> generating the wrong info?

I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)

Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]     ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2015-08-22 22:06       ` Richard Sharpe
       [not found]         ` <CACyXjPx81fh_jeQSUjE-_w8NQ_Jr-ajmnVWSopfzcLPOWoGmGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2015-08-22 23:34       ` Guy Harris
  2015-08-26 22:56       ` Simon Barber
  2 siblings, 1 reply; 14+ messages in thread
From: Richard Sharpe @ 2015-08-22 22:06 UTC (permalink / raw)
  To: Guy Harris; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Sat, Aug 22, 2015 at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
>
> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I have some 802.11ad captures because of some fixes to the Wireshark
>> 802.11 dissector I am looking at doing.
>>
>> One thing I notice is that the radiotap header contains both a Channel field
>> and an MCS field.
>
> That is to be expected for 11n packets.
>
>> The Present flags say that Flags are present, Channel is present and
>> HT Information is present.
>
> By "HT Information" do you mean "the MCS field"?

I suspect so. The Present flags are 0x0a000800. The HT information
present flag appears to indicate that MCS information is present.

> The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.
>
>> The channel frequency is 60480MHz which seems to be reasonable.
>>
>> The MCS field says that the MCS index is present and that index is 0.
>>
>> It seems to me that this last field is perhaps incorrect, because the
>> radiotap information dissector claims that the PHY type is 802.11n,
>> and that seems to come about because the radiotap header use the MCS
>> index info to claim that the PHY type was 802.11n.
>
> Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.
>
> From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
>
>         The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
>
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.
>
>> Should I be letting the capture hardware vendor know that they are
>> generating the wrong info?
>
> I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)
>
> Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

I suspect that it would but I do not have any captures where the
A-MPDU Status is listed as present.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]         ` <CACyXjPx81fh_jeQSUjE-_w8NQ_Jr-ajmnVWSopfzcLPOWoGmGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-08-22 22:24           ` Guy Harris
  0 siblings, 0 replies; 14+ messages in thread
From: Guy Harris @ 2015-08-22 22:24 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A


On Aug 22, 2015, at 3:06 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Sat, Aug 22, 2015 at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
>> 
>> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 
>>> The Present flags say that Flags are present, Channel is present and
>>> HT Information is present.
>> 
>> By "HT Information" do you mean "the MCS field"?
> 
> I suspect so. The Present flags are 0x0a000800. The HT information
> present flag appears to indicate that MCS information is present.

The Wireshark dissector refers to the MCS field as the "HT information" field when dissecting the presence flags.

(Note that Wireshark is not the authoritative reference for anything in radiotap.)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]     ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  2015-08-22 22:06       ` Richard Sharpe
@ 2015-08-22 23:34       ` Guy Harris
       [not found]         ` <1606812C-649C-4C06-ABE0-AE2F4474BCD0-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  2015-08-26 22:56       ` Simon Barber
  2 siblings, 1 reply; 14+ messages in thread
From: Guy Harris @ 2015-08-22 23:34 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A


On Aug 22, 2015, at 1:59 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:

> From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
> 
> 	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
> 
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.

For what it's worth, it appears that the wil6210 driver:

	https://wireless.wiki.kernel.org/en/users/drivers/wil6210

uses the MCS field and its mcs value for 11ad.  It can also be configured to supply raw "PHY data" with a vendor-namespace field.

So code that processes radiotap headers, such as Wireshark's radiotap-header dissector, will have to interpret packets with an MCS field and a channel frequence in the 11ad range as being 11ad packets, and treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]         ` <1606812C-649C-4C06-ABE0-AE2F4474BCD0-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2015-08-24  7:40           ` Johannes Berg
       [not found]             ` <1440402013.3735.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Johannes Berg @ 2015-08-24  7:40 UTC (permalink / raw)
  To: Guy Harris, Richard Sharpe; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
> 
> For what it's worth, it appears that the wil6210 driver:
> 
> 	https://wireless.wiki.kernel.org/en/users/drivers/wil6210
> 
> uses the MCS field and its mcs value for 11ad.  It can also be 
> configured to supply raw "PHY data" with a vendor-namespace field.
> 
> So code that processes radiotap headers, such as Wireshark's radiotap
> -header dissector, will have to interpret packets with an MCS field 
> and a channel frequence in the 11ad range as being 11ad packets, and 
> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.

That just seems really lazy though - I think we should rather fix that
driver and define a proper 60G radiotap field.

johannes

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]             ` <1440402013.3735.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
@ 2015-08-24 16:21               ` Richard Sharpe
       [not found]                 ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Sharpe @ 2015-08-24 16:21 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Guy Harris, radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
>>
>> For what it's worth, it appears that the wil6210 driver:
>>
>>       https://wireless.wiki.kernel.org/en/users/drivers/wil6210
>>
>> uses the MCS field and its mcs value for 11ad.  It can also be
>> configured to supply raw "PHY data" with a vendor-namespace field.
>>
>> So code that processes radiotap headers, such as Wireshark's radiotap
>> -header dissector, will have to interpret packets with an MCS field
>> and a channel frequence in the 11ad range as being 11ad packets, and
>> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
>
> That just seems really lazy though - I think we should rather fix that
> driver and define a proper 60G radiotap field.

Can I suggest something like the following, although we have defined
the presence flags as a UINT32 for the moment in Wireshark:

--- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
13:34:23.633866699 -0700
+++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
@@ -190,6 +190,11 @@
  * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
  *
  * Contains VHT information about this frame.
+ *
+ * IEEE80211_RADIOTAP_DMG       u8, u8
+ *
+ *      Contains DMG information about the frame. Currently presence flags
+ *      and the MCS index, if present.
  */
 enum ieee80211_radiotap_type {
  IEEE80211_RADIOTAP_TSFT = 0,
@@ -214,6 +219,7 @@
  IEEE80211_RADIOTAP_MCS = 19,
  IEEE80211_RADIOTAP_AMPDU_STATUS = 20,
  IEEE80211_RADIOTAP_VHT = 21,
+ IEEE80211_RADIOTAP_DMG = 22,

  /* valid in every it_present bitmap, even vendor namespaces */
  IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,

Also, there is the matter of whether or not we need to indicate Static
Tone Pairing and Dynamic Tone Pairing as that is a bit in the PHY
header and is needed to make sense of MCS values 13-17, maybe.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                 ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-08-24 16:28                   ` Johannes Berg
  2015-08-26 22:59                   ` Simon Barber
  1 sibling, 0 replies; 14+ messages in thread
From: Johannes Berg @ 2015-08-24 16:28 UTC (permalink / raw)
  To: Richard Sharpe; +Cc: Guy Harris, radiotap-S783fYmB3Ccdnm+yROfE0A

On Mon, 2015-08-24 at 09:21 -0700, Richard Sharpe wrote:
> On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> > On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
> > > 
> > > For what it's worth, it appears that the wil6210 driver:
> > > 
> > >       https://wireless.wiki.kernel.org/en/users/drivers/wil6210
> > > 
> > > uses the MCS field and its mcs value for 11ad.  It can also be
> > > configured to supply raw "PHY data" with a vendor-namespace field.
> > > 
> > > So code that processes radiotap headers, such as Wireshark's radiotap
> > > -header dissector, will have to interpret packets with an MCS field
> > > and a channel frequence in the 11ad range as being 11ad packets, and
> > > treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
> > 
> > That just seems really lazy though - I think we should rather fix that
> > driver and define a proper 60G radiotap field.
> 
> Can I suggest something like the following, although we have defined
> the presence flags as a UINT32 for the moment in Wireshark:
> 
> --- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
> 13:34:23.633866699 -0700
> +++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
> @@ -190,6 +190,11 @@
>   * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
>   *
>   * Contains VHT information about this frame.
> + *
> + * IEEE80211_RADIOTAP_DMG       u8, u8
> + *
> + *      Contains DMG information about the frame. Currently presence flags
> + *      and the MCS index, if present.
> 

I'm not sure that'll work - the format can't really be variable, so
having presence flags and just the MCS isn't useful (since if you don't
know the MCS, then you might as well not include the DMG field at all)

We need to define the full set of information we might want, but I'm
not nearly familiar enough with DMG to suggest what might be needed.

johannes

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]     ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  2015-08-22 22:06       ` Richard Sharpe
  2015-08-22 23:34       ` Guy Harris
@ 2015-08-26 22:56       ` Simon Barber
  2 siblings, 0 replies; 14+ messages in thread
From: Simon Barber @ 2015-08-26 22:56 UTC (permalink / raw)
  To: Guy Harris, Richard Sharpe; +Cc: radiotap-S783fYmB3Ccdnm+yROfE0A

I've never seen a capture file with a correct or useful A-MPDU field! 
I'd also like to know more information - such as what amount of padding 
was there between MPDUs in the A-MPDU.

Simon

On 8/22/2015 1:59 PM, Guy Harris wrote:
> On Aug 22, 2015, at 12:41 PM, Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> I have some 802.11ad captures because of some fixes to the Wireshark
>> 802.11 dissector I am looking at doing.
>>
>> One thing I notice is that the radiotap header contains both a Channel field
>> and an MCS field.
> That is to be expected for 11n packets.
>
>> The Present flags say that Flags are present, Channel is present and
>> HT Information is present.
> By "HT Information" do you mean "the MCS field"?
>
> The "MCS" field should, perhaps, have been called the "HT" field, as it's information for the HT (11n) PHY, just as the VHT field is information for the VHT (11ac) PHY.
>
>> The channel frequency is 60480MHz which seems to be reasonable.
>>
>> The MCS field says that the MCS index is present and that index is 0.
>>
>> It seems to me that this last field is perhaps incorrect, because the
>> radiotap information dissector claims that the PHY type is 802.11n,
>> and that seems to come about because the radiotap header use the MCS
>> index info to claim that the PHY type was 802.11n.
> Well, to be fair, that's the Wireshark code doing that, under the non-unreasonable assumption that if there's an MCS field it's an HT frame, just as it assumes that if there's a VHT field it's a VHT frame.
>
>  From the *radiotap* point of view, I would say that the last field is incorrect because the page for the MCS field on the radiotap site says:
>
> 	The mcs field indicates the MCS rate index as in IEEE_802.11n-2009.
>
> which, if we update it to say "as in Clause 20 of IEEE 802.11-2012", means it has values from 0 to 76, with modulations different from the ones in 11ad's Clause 21, i.e. the radiotap MCS field is *not* appropriate for 11ad.
>
>> Should I be letting the capture hardware vendor know that they are
>> generating the wrong info?
> I'm not even remotely an expert on 802.11 at the PHY level, but I suspect that what we really want for radiotap is a "DMG" field, containing 11ad-specific information.  It would include its own mcs field, giving the MCS values from Clause 21, and perhaps other information, such as a flag to indicate whether "Static Tone Pairing" or "Dynamic Tone Pairing" was used.  (Again, I leave it up to people more familiar with 802.11ad to decide what information would be useful.)
>
> Would the existing A-MPDU field suffice for MPDUs inside an 11ad A-MPDU?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                 ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2015-08-24 16:28                   ` Johannes Berg
@ 2015-08-26 22:59                   ` Simon Barber
       [not found]                     ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  1 sibling, 1 reply; 14+ messages in thread
From: Simon Barber @ 2015-08-26 22:59 UTC (permalink / raw)
  To: Richard Sharpe, Johannes Berg; +Cc: Guy Harris, radiotap-S783fYmB3Ccdnm+yROfE0A

The HT and VHT fields are missing various bits of phy layer info, and 
are defined missing enough bits for other fields. I've always thought It 
would be much simpler if these fields could convey the whole SIGNAL bits 
from the PLCP header, along with a mask in case it's not all available. 
The drivers I've seen have the whole PLCP SIGNAL field available.

Simon

On 8/24/2015 9:21 AM, Richard Sharpe wrote:
> On Mon, Aug 24, 2015 at 12:40 AM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>> On Sat, 2015-08-22 at 16:34 -0700, Guy Harris wrote:
>>> For what it's worth, it appears that the wil6210 driver:
>>>
>>>        https://wireless.wiki.kernel.org/en/users/drivers/wil6210
>>>
>>> uses the MCS field and its mcs value for 11ad.  It can also be
>>> configured to supply raw "PHY data" with a vendor-namespace field.
>>>
>>> So code that processes radiotap headers, such as Wireshark's radiotap
>>> -header dissector, will have to interpret packets with an MCS field
>>> and a channel frequence in the 11ad range as being 11ad packets, and
>>> treat the mcs value in the MCS field as an 11ad MCS, not an 11n MCS.
>> That just seems really lazy though - I think we should rather fix that
>> driver and define a proper 60G radiotap field.
> Can I suggest something like the following, although we have defined
> the presence flags as a UINT32 for the moment in Wireshark:
>
> --- ../linux-3.11-rc6/include/net/ieee80211_radiotap.h 2013-10-20
> 13:34:23.633866699 -0700
> +++ ./include/net/ieee80211_radiotap.h 2015-08-24 09:12:12.416137951 -0700
> @@ -190,6 +190,11 @@
>    * IEEE80211_RADIOTAP_VHT u16, u8, u8, u8[4], u8, u8, u16
>    *
>    * Contains VHT information about this frame.
> + *
> + * IEEE80211_RADIOTAP_DMG       u8, u8
> + *
> + *      Contains DMG information about the frame. Currently presence flags
> + *      and the MCS index, if present.
>    */
>   enum ieee80211_radiotap_type {
>    IEEE80211_RADIOTAP_TSFT = 0,
> @@ -214,6 +219,7 @@
>    IEEE80211_RADIOTAP_MCS = 19,
>    IEEE80211_RADIOTAP_AMPDU_STATUS = 20,
>    IEEE80211_RADIOTAP_VHT = 21,
> + IEEE80211_RADIOTAP_DMG = 22,
>
>    /* valid in every it_present bitmap, even vendor namespaces */
>    IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,
>
> Also, there is the matter of whether or not we need to indicate Static
> Tone Pairing and Dynamic Tone Pairing as that is a bit in the PHY
> header and is needed to make sense of MCS values 13-17, maybe.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                     ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
@ 2015-08-27  1:17                       ` Guy Harris
       [not found]                         ` <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  2015-09-17 16:32                       ` Johannes Berg
  1 sibling, 1 reply; 14+ messages in thread
From: Guy Harris @ 2015-08-27  1:17 UTC (permalink / raw)
  To: Simon Barber
  Cc: Richard Sharpe, Johannes Berg, radiotap-S783fYmB3Ccdnm+yROfE0A


On Aug 26, 2015, at 3:59 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:

> The HT and VHT fields are missing various bits of phy layer info, and are defined missing enough bits for other fields. I've always thought It would be much simpler if these fields could convey the whole SIGNAL bits from the PLCP header, along with a mask in case it's not all available. The drivers I've seen have the whole PLCP SIGNAL field available.

So that's the L-SIG bits from 20.3.9.3.5 "L-SIG definition", and either the HT-SIG bits from 20.3.9.4.3 "HT-SIG definition" or the VHT-SIG-A bits from 11ac's 22.3.8.3.3 "VHT-SIG-A definition" and the VHT-SIG-B bits from 11ac's 22.3.8.3.6 "VHT-SIG-B definition"?

And for 11ad, would it be the bits from 21.5.3.1.1 "General"?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                         ` <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2015-09-10 18:25                           ` Guy Harris
       [not found]                             ` <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
  0 siblings, 1 reply; 14+ messages in thread
From: Guy Harris @ 2015-09-10 18:25 UTC (permalink / raw)
  To: radiotap-S783fYmB3Ccdnm+yROfE0A
  Cc: Simon Barber, Richard Sharpe, Johannes Berg


On Aug 26, 2015, at 6:17 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:

> On Aug 26, 2015, at 3:59 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:
> 
>> The HT and VHT fields are missing various bits of phy layer info, and are defined missing enough bits for other fields. I've always thought It would be much simpler if these fields could convey the whole SIGNAL bits from the PLCP header, along with a mask in case it's not all available. The drivers I've seen have the whole PLCP SIGNAL field available.
> 
> So that's the L-SIG bits from 20.3.9.3.5 "L-SIG definition"

I.e., L_DATARATE and L_LENGTH?

> and either the HT-SIG bits from 20.3.9.4.3 "HT-SIG definition"

I.e.:

	the MCS index

	CBW 20/40

	HT Length

	Smoothing

	Not Sounding

	Aggregation (PPDU contains an A-MPDU)

	STBC

	FEC coding

	Short GI

	N(ESS)

	CRC of the bits

	Tail Bits

The ones that aren't in the MCS field or the A-MPDU field are:

	HT Length - is that just the length of the data following the radiotap header?

	Smoothing

	Not Sounding

	CRC - is this of any interest?

	Tail Bits - always 0, so these are presumably not of interest

Can:

	whether "20" means "20", "20L", or "20U";

	HT mixed vs. greenfield;

both of which are available from the MCS field, be determined from the PLCP header?

Or is what "20" means not fully determinable for received packets, so that "20L", "20U", and "40" are indistinguishable, similar to what the Radiotap spec for the VHT field says?

20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format of the HT-SIG of an HT-greenfield format frame is identical to the HT-SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if that information can be determined for received frames, it sounds as if greenfield vs. mixed *can't* be determined from the HT-SIG bits.

> or the VHT-SIG-A bits from 11ac's 22.3.8.3.3 "VHT-SIG-A definition" and the VHT-SIG-B bits from 11ac's 22.3.8.3.6 "VHT-SIG-B definition"?

I.e.:

	BW

	STBC

	Group ID

	NSTS/Partial AID

	TXOPS_PS_NOT_ALLOWED

	Short GI

	Short GI NSYM Disambiguation

	SU/MU[0] Coding

	LDPC Extra OFDM Symbol

	SU VHT-MCS/MU[1-3] Coding

	Beamformed

	CRC

	Tail Bits

The ones that aren't in the MCS field are:

	CRC - is this of any interest?

	Tail Bits - always 0, so these are presumably not of interest

The spec for the VHT field says that NSTS "can be calculated from the NSS for that user and the STBC flag" and that, for received frames, the only bandwidth information you get is 20/40/80/160, which is presumably what you can get from BW.

For *transmitted* frames, I guess you have more control over how it's transmitted, which is presumably why there's a VHT field rather than just a PLCP header field.

I.e., as radiotap is used for transmission, it needs to include at least some of the parameters to the PHY service's transmission operation, which may not be available in the PLCP header.

> And for 11ad, would it be the bits from 21.5.3.1.1 "General"?

I.e.:

	Scrambler Initialization - probably not of interest

	MCS

	Length - is this just the length of the data following the radiotap header?

	Additional PPDU

	Packet Type

	Training Length

	Aggregation (PPDU contains an A-MPDU)

	Beam Tracking Request

	Tone Pairing Type

	DTP Indicator

	Last RSSI

	Turnaround

	HCS (a CRC)

So do we need all of those?

And is there anything more that would be needed for *injected* 11ad frames?  If so, that's an argument for a "DMG" field containing the interesting information from the PLCP header combined with information necessary for injected frames?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                     ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
  2015-08-27  1:17                       ` Guy Harris
@ 2015-09-17 16:32                       ` Johannes Berg
  1 sibling, 0 replies; 14+ messages in thread
From: Johannes Berg @ 2015-09-17 16:32 UTC (permalink / raw)
  To: Simon Barber, Richard Sharpe; +Cc: Guy Harris, radiotap-S783fYmB3Ccdnm+yROfE0A

On Wed, 2015-08-26 at 15:59 -0700, Simon Barber wrote:
> The HT and VHT fields are missing various bits of phy layer info, and 
> 
> are defined missing enough bits for other fields. I've always thought It 
> would be much simpler if these fields could convey the whole SIGNAL bits 
> from the PLCP header, along with a mask in case it's not all available. 
> The drivers I've seen have the whole PLCP SIGNAL field available.
> 

What drivers have you been looking at? Most I've seen don't actually
have it.

I don't really object to this proposal though - the mask would be very
much needed though and one might have to re-construct the signal field
from available data.

johannes

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Correct radiotap header for 802.11ad
       [not found]                             ` <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2015-09-17 16:37                               ` Johannes Berg
  0 siblings, 0 replies; 14+ messages in thread
From: Johannes Berg @ 2015-09-17 16:37 UTC (permalink / raw)
  To: Guy Harris, radiotap-S783fYmB3Ccdnm+yROfE0A; +Cc: Simon Barber, Richard Sharpe

On Thu, 2015-09-10 at 11:25 -0700, Guy Harris wrote:
> 
> The ones that aren't in the MCS field or the A-MPDU field are:
> 
> 	HT Length - is that just the length of the data following 
> the radiotap header?

I don't think so - at least not with A-MPDU.

> 	Smoothing
> 
> 	Not Sounding
> 
> 	CRC - is this of any interest?
> 
> 	Tail Bits - always 0, so these are presumably not of 
> interest
> 
> Can:
> 
> 	whether "20" means "20", "20L", or "20U";
> 
> 	HT mixed vs. greenfield;
> 
> both of which are available from the MCS field, be determined from 
> the PLCP header?
> 
> Or is what "20" means not fully determinable for received packets, so 
> that "20L", "20U", and "40" are indistinguishable, similar to what 
> the Radiotap spec for the VHT field says?

I have a hard time seeing 20L/20U being distinguishable if you're
hearing those while tuned to a 20 MHz channel, but if you're tuned to a
40 MHz channel then perhaps that's possible - likely not from the PLCP
though since that would have to look like a regular 20 MHz transmission
for purposes of somebody picking it up on a 20 MHz channel? I'm not
really all that familiar with the PHY details though.

> 20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format 
> of the HT-SIG of an HT-greenfield format frame is identical to the HT
> -SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if 
> that information can be determined for received frames, it sounds as 
> if greenfield vs. mixed *can't* be determined from the HT-SIG bits.

You can know whether or not it was preceded by a compat preamble
though.

> For *transmitted* frames, I guess you have more control over how it's 
> transmitted, which is presumably why there's a VHT field rather than 
> just a PLCP header field.
> 
> I.e., as radiotap is used for transmission, it needs to include at 
> least some of the parameters to the PHY service's transmission 
> operation, which may not be available in the PLCP header.

That's also a good point - having to build a PLCP signal field for
transmission would be somewhat painful, especially if you just want to
control some part of the transmission.

> And is there anything more that would be needed for *injected* 11ad 
> frames?  If so, that's an argument for a "DMG" field containing the 
> interesting information from the PLCP header combined with 
> information necessary for injected frames?

Not being familiar with DMG, I can't really comment on this.

It does sound like we need *some* new field though, be it either a DMG
field or a PLCP SIGNAL field, or perhaps even both.

Going back to the original thread though, I think using the MCS field
is quite wrong.

johannes

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, back to index

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-22 19:41 Correct radiotap header for 802.11ad Richard Sharpe
     [not found] ` <CACyXjPzq-ePB1ux6wi_Rv3onPKXomcJcm15XJwA51u0E4W2txw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 20:59   ` Guy Harris
     [not found]     ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-22 22:06       ` Richard Sharpe
     [not found]         ` <CACyXjPx81fh_jeQSUjE-_w8NQ_Jr-ajmnVWSopfzcLPOWoGmGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 22:24           ` Guy Harris
2015-08-22 23:34       ` Guy Harris
     [not found]         ` <1606812C-649C-4C06-ABE0-AE2F4474BCD0-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-24  7:40           ` Johannes Berg
     [not found]             ` <1440402013.3735.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-08-24 16:21               ` Richard Sharpe
     [not found]                 ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 16:28                   ` Johannes Berg
2015-08-26 22:59                   ` Simon Barber
     [not found]                     ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2015-08-27  1:17                       ` Guy Harris
     [not found]                         ` <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-10 18:25                           ` Guy Harris
     [not found]                             ` <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-17 16:37                               ` Johannes Berg
2015-09-17 16:32                       ` Johannes Berg
2015-08-26 22:56       ` Simon Barber

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git