MCS field: RFA

MCS field: RFA

[Matteo Croce]

Hi,
the MCS filed is in the suggested fields since about a month, now I
request its approval.

Here is the draft of the field: http://www.radiotap.org/suggested-fields/MCS

and here there are patches for the radiotap parser, mac80211, tcpdump
and wireshark:

http://teknoraver.net/software/radiotap_mcs/

Before it's approved I would ask the crew what is the best thing to do
with the old rate field
when the MCS one is set.
We can leave it set with a value of 0 or just omitting it when the MCS is set.
The latter makes more sense to me.

Cheers,
Matteo Croce

Re: MCS field: RFA

[David Young]

On Tue, Jan 26, 2010 at 03:26:07PM +0100, Matteo Croce wrote:
> Hi,
> the MCS filed is in the suggested fields since about a month, now I
> request its approval.
> 
> Here is the draft of the field: http://www.radiotap.org/suggested-fields/MCS

FreeBSD uses the flags field and the channel flags to indicate Short
GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
purpose.

I think that it may be a good idea to add an MCS rate field instead of
to overload the legacy rate field, as FreeBSD does.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: MCS field: RFA

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Tue, 2010-01-26 at 11:47 -0600, David Young wrote:

> FreeBSD uses the flags field and the channel flags to indicate Short
> GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
> purpose.

I'd mostly agree, but I'm not sure what they really use the 40MHz flag
for. For instance, might there be value in knowing that the AP opened
the channel for 40MHz, but for some reason we are doing 20MHz
transmissions instead? And would this be an appropriate way of
conferring that information?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: MCS field: RFA

[David Young]

On Wed, Jan 27, 2010 at 10:36:05AM +0100, Johannes Berg wrote:
> On Tue, 2010-01-26 at 11:47 -0600, David Young wrote:
> 
> > FreeBSD uses the flags field and the channel flags to indicate Short
> > GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
> > purpose.
> 
> I'd mostly agree, but I'm not sure what they really use the 40MHz flag
> for. For instance, might there be value in knowing that the AP opened
> the channel for 40MHz, but for some reason we are doing 20MHz
> transmissions instead? And would this be an appropriate way of
> conferring that information?

I should take a closer look at the implementation.  A per-packet radio
information header does not need to carry the information of what the
AP could have done, but didn't, does it?  I think it should carry the
information that describes the properties of the packet.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: MCS field: RFA

[Matteo Croce]

On Wed, Jan 27, 2010 at 4:30 PM, David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Jan 27, 2010 at 10:36:05AM +0100, Johannes Berg wrote:
>> On Tue, 2010-01-26 at 11:47 -0600, David Young wrote:
>>
>> > FreeBSD uses the flags field and the channel flags to indicate Short
>> > GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
>> > purpose.
>>
>> I'd mostly agree, but I'm not sure what they really use the 40MHz flag
>> for. For instance, might there be value in knowing that the AP opened
>> the channel for 40MHz, but for some reason we are doing 20MHz
>> transmissions instead? And would this be an appropriate way of
>> conferring that information?
>
> I should take a closer look at the implementation.  A per-packet radio
> information header does not need to carry the information of what the
> AP could have done, but didn't, does it?  I think it should carry the
> information that describes the properties of the packet.
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933
>

The channel width is a packet property in 802.11n IIRC

Re: MCS field: RFA

[Bill Stafford]

Matteo Croce <technoboy85@...> writes:
> On Wed, Jan 27, 2010 at 4:30 PM, David Young <dyoung@...> wrote:
> > On Wed, Jan 27, 2010 at 10:36:05AM +0100, Johannes Berg wrote:
> >> On Tue, 2010-01-26 at 11:47 -0600, David Young wrote:
> >>
> >> > FreeBSD uses the flags field and the channel flags to indicate Short
> >> > GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
> >> > purpose.
> >>
> >> I'd mostly agree, but I'm not sure what they really use the 40MHz flag
> >> for. For instance, might there be value in knowing that the AP opened
> >> the channel for 40MHz, but for some reason we are doing 20MHz
> >> transmissions instead? And would this be an appropriate way of
> >> conferring that information?
> >
> > I should take a closer look at the implementation.  A per-packet radio
> > information header does not need to carry the information of what the
> > AP could have done, but didn't, does it?  I think it should carry the
> > information that describes the properties of the packet.
> > 
> The channel width is a packet property in 802.11n IIRC

Yes, it is in both the TXVECTOR and RXVECTOR of the PHY service interface.

The MCS field description (http://www.radiotap.org/suggested-fields/MCS)
just shows a bit for 40 MHz Channel and a bit for Short GI.

On the "40 MHz Channel" bit, it seems like it make more sense as "40 MHz
transmission". That is, it is a description of the modulation of the
packet, not a description of the channel to which the radio is currently
tuned. But there is more to the packet bandwidth than just 20 vs 40
MHz. When a device is tuned to a 40 MHz channel, it may receive 20 MHz
packets on either half of the 40-wide channel.

So the bandwidth options for a packet when the device is tuned to a 40 MHz
channel are:
40 MHz (full 40 MHz bandwidth packet)
20L (20 MHz packet in the lower 20 MHz of the 40 MHz channel)
20U (20 MHz packet in the upper 20 MHz of the 40 MHz channel)

When tuned to a 20 MHz channel, the packets can only be 20MHz

There are other parameters to the modulation that seem like they are all
important. A field that is going to capture the MCS, transmission
bandwidth, and short/long GI, should also note the HT Format of
Mixed/Greenfield, and the FEC (Forward Error Correction) mode BCC/LDPC.

So should the flags be:
0x03 - Bandwidth (0 -> 20 MHz, 1 -> 40 MHz, 2 -> 20L, 3 -> 20U)
0x04 - GI (0 -> Long, 1 -> Short)
0x10 - Format (0 -> Mixed, 1 -> Greenfield)
0x20 - FEC mode (0 -> BCC, 1 -> LDPC)

I also have a question about how the RadioTap design deals with information
that may not be available. I know that RadioTap works for many different
drivers, and I am wondering if all the drivers get full information about
the packets. For example, is it better to have a single bit for the GI
Short/Long, or two bits? If there were two bits, one for Short GI, and one
for Long GI, then a driver that did not get the GI information at all would
send up a RadioTap header with neither bit set, indicating nothing about
the GI of the packet. If there is only one bit, then by not setting the
Short GI bit in the field, it is indicating a Long GI.

Also, on the use of RadioTap for a user app to attach modulation
information, using separate bits might be a way to leave the choice up to
the driver. So if the user app just wanted to send a frame with a
particular MCS, it could use this field, but leave both the Short GI and
Long GI bits zero, so that the driver would pick whatever is appropriate.

So if it was in this longer format the flags might be something like this:
0x0001 20 MHz
0x0002 40 MHz
0x0004 20L (20 MHz in lower half of 40 MHz channel)
0x0008 20U (20 MHz in upper half of 40 MHz channel)
0x0010 Long GI
0x0020 Short GI
0x0040 HT Format - Mixed
0x0080 HT Format - Greenfield
0x0100 FEC type BCC
0x0200 FEC type LDPC

It seems like this expanded bitfield might be better than the more compact
version.

On Tue, 2010-01-26 at 11:47 -0600, David Young wrote:
> FreeBSD uses the flags field and the channel flags to indicate Short
> GI and 40 MHz frames.  Let's adopt the FreeBSD definitions for that
> purpose.

I can see using the channel bandwidth to indicate the packet transmission
bandwidth. In the expanded bit format above it would mean dropping the 20 MHz
and 40 MHz bits. When the radio is tuned to a 20 MHz channel, assume 20MHz
packets, and when tuned to 40 MHz assume 40 MHz packets. That covers the full
channel bandwidth modulations, but leaves 20-in-40 MHz packet modulations to be
addressed.

When the radio is tuned to a 40 MHz channel, then the 20L and 20U bits could
indicate a 20 MHz packet on the lower or upper side of the 40 MHz channel. I
think leaving in the 20L/U bits would be better than changing the channel field
to indicate the modulation of the packet. It might be better to leave the
channel field describing the channel to which the radio is tuned, and these
20U/L bits to indicate how the receiver saw the packets. When capturing packets,
it would seem surprising to see the channel field indicating channel changes on
what might be a packet by packet basis. On the transmit side, where radiotap is
describing a frame transmit, it seems like it would be better to leave the
channel field indicating a 40 MHz channel, and use the 20U/L bits when sending
20-in-40 MHz packets, or leaving them clear to do a straight 40 MHz
transmission. Changing the channel bandwidth might lead a driver to switch how
the radio is tuned which might be inefficient on what might be a packet by
packet change.

The GI short/long attribute really seems to belong to info related to the packet
modulation, not an attribute of the channel to which the radio is tuned.

-Bill

Re: MCS field: RFA

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Mon, 2010-02-01 at 22:09 +0000, Bill Stafford wrote:

> I also have a question about how the RadioTap design deals with information
> that may not be available. 

That's a good point.

> So if it was in this longer format the flags might be something like this:
> 0x0001 20 MHz
> 0x0002 40 MHz
> 0x0004 20L (20 MHz in lower half of 40 MHz channel)
> 0x0008 20U (20 MHz in upper half of 40 MHz channel)
> 0x0010 Long GI
> 0x0020 Short GI
> 0x0040 HT Format - Mixed
> 0x0080 HT Format - Greenfield
> 0x0100 FEC type BCC
> 0x0200 FEC type LDPC
> 
> It seems like this expanded bitfield might be better than the more compact
> version.

Which speaks much in favour of this way, even though it may seem
redundant it would allow implementations to say "don't know about
upper/lower but do know it's 20mhz".

> When the radio is tuned to a 40 MHz channel, then the 20L and 20U bits could
> indicate a 20 MHz packet on the lower or upper side of the 40 MHz channel. I
> think leaving in the 20L/U bits would be better than changing the channel field
> to indicate the modulation of the packet. It might be better to leave the
> channel field describing the channel to which the radio is tuned, and these
> 20U/L bits to indicate how the receiver saw the packets. When capturing packets,
> it would seem surprising to see the channel field indicating channel changes on
> what might be a packet by packet basis.

That was my gut feeling as well, but it's a pure definition problem. We
do currently use the OFDM/CCK etc. bits in there on a per-packet basis
too, for instance, and they don't really make sense per-channel anyway.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: MCS field: RFA

[David Young]

On Mon, Feb 01, 2010 at 10:09:37PM +0000, Bill Stafford wrote:
> The MCS field description (http://www.radiotap.org/suggested-fields/MCS)
> just shows a bit for 40 MHz Channel and a bit for Short GI.
> 
> On the "40 MHz Channel" bit, it seems like it make more sense as "40 MHz
> transmission". That is, it is a description of the modulation of the
> packet, not a description of the channel to which the radio is currently
> tuned. But there is more to the packet bandwidth than just 20 vs 40
> MHz. When a device is tuned to a 40 MHz channel, it may receive 20 MHz
> packets on either half of the 40-wide channel.
> 
> So the bandwidth options for a packet when the device is tuned to a 40 MHz
> channel are:
> 40 MHz (full 40 MHz bandwidth packet)
> 20L (20 MHz packet in the lower 20 MHz of the 40 MHz channel)
> 20U (20 MHz packet in the upper 20 MHz of the 40 MHz channel)
> 
> When tuned to a 20 MHz channel, the packets can only be 20MHz

My recollection of 802.11n may be incorrect, but aren't 20L and 20U HT
transmission channels aliases for the same center frequency and width as
a 20 MHz HT/legacy channel?

> I also have a question about how the RadioTap design deals with information
> that may not be available. I know that RadioTap works for many different
> drivers, and I am wondering if all the drivers get full information about
> the packets.

The problem of don't-know/don't-care flags has come up before.  It'd be
nice to have a general solution.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: MCS field: RFA

[Bill Stafford]

On Feb 2, 2010, at 11:54 AM, David Young wrote:
> On Mon, Feb 01, 2010 at 10:09:37PM +0000, Bill Stafford wrote:
>> 
>> So the bandwidth options for a packet when the device is tuned to a 40 MHz
>> channel are:
>> 40 MHz (full 40 MHz bandwidth packet)
>> 20L (20 MHz packet in the lower 20 MHz of the 40 MHz channel)
>> 20U (20 MHz packet in the upper 20 MHz of the 40 MHz channel)
>> 
>> When tuned to a 20 MHz channel, the packets can only be 20MHz
> 
> My recollection of 802.11n may be incorrect, but aren't 20L and 20U HT
> transmission channels aliases for the same center frequency and width as
> a 20 MHz HT/legacy channel?

As I understand it, those transmission modes, and rx attributes,
do represent packets on the the air that look just like packets
sent by a device tuned to the 20 MHz channels. So if a device is
on the 40 MHz channel that is the pair of {36,40}, then when it
transmits a 20L packet, it should be received by a device tuned
to the 20 MHz channel 36 just as if the transmitter had been
tuned to 36. So in that way you could think of it as an
alias---at least from what you would see on the air. But packet
reception would be from a radio that is really tuned to a 40 MHz
wide channel. I've got to assume that the transmit side would
also be operating in a 40 MHz mode as it generated the 20U or 20L
packet. So these transmit/receive modes are different than being
tuned to a 20 MHz channel.

I think it is an important piece of information for capture on
both transmit and receive. For instance, if a capture shows that
a receiver is getting a higher rate of packet errors when it
receives 20L packets from the 40 MHz channel pair {36,40}, than
it is when receiving 20 MHz packets while tuned to 36, then you
might be suspicious of how well the 20L decode is working. If the
capture just reported 20 MHz packets on 36 in both cases, you
would not have anything to go on. Same sort of example for tx.

Also, on use of RadioTap as an app level 802.11 packet format,
you would want to be able to make the distinction between
remaining on a 40 MHz channel and sending a 20L packet, and
actually switching to lower 20 MHz channel and sending a packet.

-Bill

Re: MCS field: RFA

[Joshua (Shiwei) Zhao]

In 802.11, there is no official concept of 20L or 20U. There is
primary channel and secondary channel used in a BSS. However, as a
sniffer sees a packet on the air, sniffer can only tell the packet's
bandwidth and operating channel. But we know, if a 40MHz-capable
AP/STA sends a 20MHz signal, it must use its primary channel.

So I agree with what David described using channel flag indicating
bandwidth and guard interval. A MCS field is good for HT case.

David,
where is the details about freeBSD's definition?

Thanks,
Joshua


On Tue, Feb 2, 2010 at 9:24 PM, Bill Stafford <bill.stafford-BUHhN+a2lJ4@public.gmane.org> wrote:
> On Feb 2, 2010, at 11:54 AM, David Young wrote:
>> On Mon, Feb 01, 2010 at 10:09:37PM +0000, Bill Stafford wrote:
>>>
>>> So the bandwidth options for a packet when the device is tuned to a 40 MHz
>>> channel are:
>>> 40 MHz (full 40 MHz bandwidth packet)
>>> 20L (20 MHz packet in the lower 20 MHz of the 40 MHz channel)
>>> 20U (20 MHz packet in the upper 20 MHz of the 40 MHz channel)
>>>
>>> When tuned to a 20 MHz channel, the packets can only be 20MHz
>>
>> My recollection of 802.11n may be incorrect, but aren't 20L and 20U HT
>> transmission channels aliases for the same center frequency and width as
>> a 20 MHz HT/legacy channel?
>
> As I understand it, those transmission modes, and rx attributes,
> do represent packets on the the air that look just like packets
> sent by a device tuned to the 20 MHz channels. So if a device is
> on the 40 MHz channel that is the pair of {36,40}, then when it
> transmits a 20L packet, it should be received by a device tuned
> to the 20 MHz channel 36 just as if the transmitter had been
> tuned to 36. So in that way you could think of it as an
> alias---at least from what you would see on the air. But packet
> reception would be from a radio that is really tuned to a 40 MHz
> wide channel. I've got to assume that the transmit side would
> also be operating in a 40 MHz mode as it generated the 20U or 20L
> packet. So these transmit/receive modes are different than being
> tuned to a 20 MHz channel.
>
> I think it is an important piece of information for capture on
> both transmit and receive. For instance, if a capture shows that
> a receiver is getting a higher rate of packet errors when it
> receives 20L packets from the 40 MHz channel pair {36,40}, than
> it is when receiving 20 MHz packets while tuned to 36, then you
> might be suspicious of how well the 20L decode is working. If the
> capture just reported 20 MHz packets on 36 in both cases, you
> would not have anything to go on. Same sort of example for tx.
>
> Also, on use of RadioTap as an app level 802.11 packet format,
> you would want to be able to make the distinction between
> remaining on a 40 MHz channel and sending a 20L packet, and
> actually switching to lower 20 MHz channel and sending a packet.
>
> -Bill
>
>

Re: MCS field: RFA

[Bill Stafford]

On Feb 3, 2010, at 5:11 PM, Joshua (Shiwei) Zhao wrote:
> In 802.11, there is no official concept of 20L or 20U. There is
> primary channel and secondary channel used in a BSS.

I know what you mean about about the channel definition. The IEs
in beacons and probe responses will describe a 40 MHz BSS as
having the control (primary) and extension (secondary)
channel. So if you were setting up the channel pair {36,40}, you
might pick channel 36 as control and have the extension channel
above on 40. You could also set it up as ctl 40 with extension
below on 36. Both would cover the same 40 MHz, but as you say,
the 20 MHz traffic should always go on the control channel.

But the spec does have the concept of 20U and 20L in terms of the
phy layer. Section 20.2.2 "TXVECTOR and RXVECTOR parameters"
defines the CH_OFFSET field with values {CH_OFF_20, CH_OFF_40,
CH_OFF_20U, CH_OFF_20L}. So it is not a BSS attribute, which is
where I think you are coming from, but it is an attribute of
packets both on TX and RX.

> However, as a
> sniffer sees a packet on the air, sniffer can only tell the packet's
> bandwidth and operating channel. But we know, if a 40MHz-capable
> AP/STA sends a 20MHz signal, it must use its primary channel.

Sure, any 20 MHz traffic from the first BSS I mentioned {ctl 36,
ext 40} would be on channel 36 (CH_OFF_20L, or just 20L as I
suggested). But that does not mean all 20 MHz traffic will be on
36. 20 MHz traffic from the other BSS {ext 36, ctl 40} would be
on 40, and legacy BSSs might be on either. So the sniffer would
pick up the packets as 20L or 20U while the radio was tuned to
{36,40}.

As I mentioned, you are loosing what seems like important
information if you just capture a packet as (channel 36 20MHz)
instead of (20L, channel 36-40). You can always have the sniffer
app display the resulting channel (ch36) with the second form
because it has more information. But with the first form, you've
lost the info about what the receiver mode was at the time of
capture. Also, for a user app using radio tap, using the
first form would not allow for the 20U/L transmissions.

> So I agree with what David described using channel flag indicating
> bandwidth and guard interval. A MCS field is good for HT case.


And LDPC vs BCC?

-Bill

Re: MCS field: RFA

[Joshua (Shiwei) Zhao]

For the existing chips on market, I guess none of them would receive
20MHz packets on the secondary channel though they are configured for
40MHz, i.e. they would only receive 40MHz packets or 20MHz packets on
the primary channel.
And, for the 20MHz packet you receive, isn't it enough to know their
channel? Why would I care whether it's received on the sniffer chip's
U or L channel?

Good point for LPDC. I'd say STBC also. Personally I think we can
extend the rx flags definition and add coding or other additional
informations.

Thanks,
Joshua


On Wed, Feb 3, 2010 at 9:50 PM, Bill Stafford <bill.stafford-BUHhN+a2lJ4@public.gmane.org> wrote:
> On Feb 3, 2010, at 5:11 PM, Joshua (Shiwei) Zhao wrote:
>> In 802.11, there is no official concept of 20L or 20U. There is
>> primary channel and secondary channel used in a BSS.
>
> I know what you mean about about the channel definition. The IEs
> in beacons and probe responses will describe a 40 MHz BSS as
> having the control (primary) and extension (secondary)
> channel. So if you were setting up the channel pair {36,40}, you
> might pick channel 36 as control and have the extension channel
> above on 40. You could also set it up as ctl 40 with extension
> below on 36. Both would cover the same 40 MHz, but as you say,
> the 20 MHz traffic should always go on the control channel.
>
> But the spec does have the concept of 20U and 20L in terms of the
> phy layer. Section 20.2.2 "TXVECTOR and RXVECTOR parameters"
> defines the CH_OFFSET field with values {CH_OFF_20, CH_OFF_40,
> CH_OFF_20U, CH_OFF_20L}. So it is not a BSS attribute, which is
> where I think you are coming from, but it is an attribute of
> packets both on TX and RX.
>
>> However, as a
>> sniffer sees a packet on the air, sniffer can only tell the packet's
>> bandwidth and operating channel. But we know, if a 40MHz-capable
>> AP/STA sends a 20MHz signal, it must use its primary channel.
>
> Sure, any 20 MHz traffic from the first BSS I mentioned {ctl 36,
> ext 40} would be on channel 36 (CH_OFF_20L, or just 20L as I
> suggested). But that does not mean all 20 MHz traffic will be on
> 36. 20 MHz traffic from the other BSS {ext 36, ctl 40} would be
> on 40, and legacy BSSs might be on either. So the sniffer would
> pick up the packets as 20L or 20U while the radio was tuned to
> {36,40}.
>
> As I mentioned, you are loosing what seems like important
> information if you just capture a packet as (channel 36 20MHz)
> instead of (20L, channel 36-40). You can always have the sniffer
> app display the resulting channel (ch36) with the second form
> because it has more information. But with the first form, you've
> lost the info about what the receiver mode was at the time of
> capture. Also, for a user app using radio tap, using the
> first form would not allow for the 20U/L transmissions.
>
>> So I agree with what David described using channel flag indicating
>> bandwidth and guard interval. A MCS field is good for HT case.
>
>
> And LDPC vs BCC?
>
> -Bill
>

Re: MCS field: RFA

[David Young]

On Tue, Feb 02, 2010 at 01:54:25PM -0600, David Young wrote:
> On Mon, Feb 01, 2010 at 10:09:37PM +0000, Bill Stafford wrote:
> > I also have a question about how the RadioTap design deals with information
> > that may not be available. I know that RadioTap works for many different
> > drivers, and I am wondering if all the drivers get full information about
> > the packets.
> 
> The problem of don't-know/don't-care flags has come up before.  It'd be
> nice to have a general solution.

I've been thinking about this.  Instead of adding 2**n-byte aligned
fields with don't-know/don't-care flags, what do people think about
using the presence bits in the header to indicate the presence of
1-bit-wide fields?

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: MCS field: RFA

[Johannes Berg]

On Thu, 2010-03-25 at 18:50 -0500, David Young wrote:
> On Tue, Feb 02, 2010 at 01:54:25PM -0600, David Young wrote:
> > On Mon, Feb 01, 2010 at 10:09:37PM +0000, Bill Stafford wrote:
> > > I also have a question about how the RadioTap design deals with information
> > > that may not be available. I know that RadioTap works for many different
> > > drivers, and I am wondering if all the drivers get full information about
> > > the packets.
> > 
> > The problem of don't-know/don't-care flags has come up before.  It'd be
> > nice to have a general solution.
> 
> I've been thinking about this.  Instead of adding 2**n-byte aligned
> fields with don't-know/don't-care flags, what do people think about
> using the presence bits in the header to indicate the presence of
> 1-bit-wide fields?

Seems like a good idea, but I would suggest reserving a whole block of
them, or potentially an entire namespace, so we don't end up aligning
all the time?

johannes

Re: MCS field: RFA

[Johannes Berg]

On Thu, 2010-03-25 at 21:57 -0700, Johannes Berg wrote:

> > > The problem of don't-know/don't-care flags has come up before.  It'd be
> > > nice to have a general solution.
> > 
> > I've been thinking about this.  Instead of adding 2**n-byte aligned
> > fields with don't-know/don't-care flags, what do people think about
> > using the presence bits in the header to indicate the presence of
> > 1-bit-wide fields?
> 
> Seems like a good idea, but I would suggest reserving a whole block of
> them, or potentially an entire namespace, so we don't end up aligning
> all the time?

I gave this a bit more thought, and I think I came to the conclusion
that this isn't such a great idea after all. But let me elaborate.

Adding single-bit fields has the advantage that they can be left out of
the header when, e.g., you just know the MCS, but you don't know whether
it was 20 or 40 MHz (which, incidentally, is quite useless).

However, you pay for it by alignment and waste presence bits in the
header. If you have a single 1-bit field present, then you need at least
7 more bits of padding. This can be mitigated by using 8 consecutive
presence bits, so that you just pay the alignment penalty once. You
could make a case for going to 16 then, but that wastes a lot of
presence bits.

But then assuming we use 8 presence bits/1-bit fields, as soon as any
one of them gets used (which we have to assume if they get used for HT
purposes) we use 2 bytes already. We still need the presence bit for the
MCS index as well. On a non-HT packet, we've now used up 9 presence
bits.

I think this wastes too much bits and makes things too complex. We could
reserve a namespace, but similar things happen.

Also, another point I wanted to make is that this puts related
information "far" from each other in terms of parsing the header.
Currently, when you parse a header, you can almost interpret each field
by itself. If we put HT flags and MCS information into separate
(single-bit) fields, then the data is spread apart. The spread becomes
if we'd reserve more bits and later use them.

All told, I think I'd prefer an approach where we put related
information into a single field. This leaves us two approaches (that I
can think of right now):

> So if it was in this longer format the flags might be something like
> this:
> 0x0001 20 MHz
> 0x0002 40 MHz
> 0x0004 20L (20 MHz in lower half of 40 MHz channel)
> 0x0008 20U (20 MHz in upper half of 40 MHz channel)
> 0x0010 Long GI
> 0x0020 Short GI
> 0x0040 HT Format - Mixed
> 0x0080 HT Format - Greenfield
> 0x0100 FEC type BCC
> 0x0200 FEC type LDPC

as proposed by Bill earlier in this thread, or a different approach I'd
like to point out:

known:
0x01	bandwidth
0x02	(reserved)
0x04	GI
0x08	format
0x10	FEC mode
flags:
0x03	bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U
0x04	GI
0x08	format
0x10	FEC mode

This has two advantages:
 1) there are no invalid combinations, because "0x00,0x04"
    (unknown GI, long GI) just means "unknown GI", whereas
    the other way could lead to short-GI|long-GI being set
 2) it doesn't require a 16-bit field, so no extra padding
    will be necessary

If the information is present, the amount of data is the same, but if it
is not present just a single presence bit is used. I think this is also
an advantage.

I've put a modified proposal here:
http://www.radiotap.org/suggested-fields/MCS-proposal2

I also added some a-MPDU status bits. They might not quite belong to
HT/MCS only, but they will typically be used with that and everything
else can indeed be masked out if really necessary.

Thoughts?

johannes

Re: MCS field: RFA

[Bill Stafford]

Matteo Croce <technoboy85@...> writes:
> Before it's approved I would ask the crew what is the best
> thing to do with the old rate field when the MCS one is set.
> We can leave it set with a value of 0 or just omitting it when
> the MCS is set.  The latter makes more sense to me.

Omitting the Rate field seems like the most logical, but does not
help out legacy parsers. The Rate field can represent the 20 MHz
HT rates up to MCS 14 (13 ShortGI), and some of the higher
indexes. This means a legacy parser could show accurate rate for
all but the highest phy rates if the Rate field was included.

You mention the possibility of leaving the Rate field in with a
value of 0. That would be a good obvious key for someone looking
over a capture to know that the rate could not be represented.

Another option would be to peg the rate value at the max (an odd
looking 127.5 Mbps). On the downside, this might be confusing if
someone looking over a capture did not know this was an invalid
11n data rate. But on the upside, it is helpful for wireshark
filters like "radiotap.datarate < 48" when you are trying to see
any traffic that falls below 24 Mbps for example. Even making the
filter "radiotap.datarate < 48 && radiotap.datarate != 0" would
not let you test for < 24 Mbps since some of the HT rates are
less than 24 Mbps.

Leaving the Rate field in place and setting to the max when
needed seems like it would be more helpful to legacy parsers. New
parsers can just ignore the Rate field if MCS is present and
calculate the rate from the MCS and other transmit factors (GI,
Bandwidth).

Hope this is helpful in discussion.

-Bill

Re: MCS field: RFA

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Tue, 2010-02-02 at 17:36 +0000, Bill Stafford wrote:

> Omitting the Rate field seems like the most logical, but does not
> help out legacy parsers.

I'm not sure I'm entirely convinced we should try to define this, some
implementations might not want to have a rate table for MCS rates, for
example.

> But on the upside, it is helpful for wireshark
> filters like "radiotap.datarate < 48" when you are trying to see
> any traffic that falls below 24 Mbps for example.

That would exclude any packets w/o the rate field as well, because of
the way filters work when fields are not present.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: MCS field: RFA

[David Young]

On Tue, Feb 02, 2010 at 05:36:17PM +0000, Bill Stafford wrote:
> Matteo Croce <technoboy85@...> writes:
> > Before it's approved I would ask the crew what is the best
> > thing to do with the old rate field when the MCS one is set.
> > We can leave it set with a value of 0 or just omitting it when
> > the MCS is set.  The latter makes more sense to me.
> 
> Omitting the Rate field seems like the most logical, but does not
> help out legacy parsers. The Rate field can represent the 20 MHz
> HT rates up to MCS 14 (13 ShortGI), and some of the higher
> indexes. This means a legacy parser could show accurate rate for
> all but the highest phy rates if the Rate field was included.
> 
> You mention the possibility of leaving the Rate field in with a
> value of 0. That would be a good obvious key for someone looking
> over a capture to know that the rate could not be represented.

I favor omitting the legacy rate field from HT frames.

In standards-ese, I propose:

        An implementation SHOULD NOT use the legacy rate field to
        represent the transmission rate of any HT frame.

        If the legacy rate field cannot perfectly represent a
        frame's transmission rate (e.g., it is a 288.9 Mbps HT
        frame), an implementation MUST omit the legacy rate field.

Even if the legacy field can represent the HT rate, it may be misleading
to compare the legacy rate field in an HT frame with the legacy rate
field in a legacy frame, because of the different types and amount of
overhead involved in the HT & legacy transmissions.  Also, comparing the
legacy rate of two HT transmissions, one whose rate is representable in
the legacy rate field and one whose rate is not representable, will not
be too useful.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: MCS field: RFA (wireshark patch)

[Bill Stafford]

Matteo Croce <technoboy85@...> writes:
> and here there are patches for the radiotap parser, mac80211, tcpdump
> and wireshark:
> 
> http://teknoraver.net/software/radiotap_mcs/

What version of Wireshark is this patch for? I tried to apply it to 1.2.5 from
http://anonsvn.wireshark.org/viewvc/releases/wireshark-1.2.5/, but the files
from your patch: Index:

wireshark/epan/dissectors/packet-radiotap-defs.h Index:
wireshark/epan/dissectors/packet-radiotap-iter.c

Are not in the sources. They look like extractions from packet-radiotap.c

Also, wireshark 1.2.5 has this at the end of the packet-radiotap.c:enum
ieee80211_radiotap_type def:

    IEEE80211_RADIOTAP_DB_ANTNOISE = 13,
    IEEE80211_RADIOTAP_RX_FLAGS = 14,
    IEEE80211_RADIOTAP_XCHANNEL = 18,
    IEEE80211_RADIOTAP_EXT = 31
};

But your patch has:
 	IEEE80211_RADIOTAP_TX_FLAGS = 15,
 	IEEE80211_RADIOTAP_RTS_RETRIES = 16,
 	IEEE80211_RADIOTAP_DATA_RETRIES = 17,
+	IEEE80211_RADIOTAP_RATE_MCS = 19,
 
 	/* valid in every it_present bitmap, even vendor namespaces */
 	IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,

So it looks like quite a bit different.

Re: MCS field: RFA (wireshark patch)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Sat, 2010-02-06 at 20:02 +0000, Bill Stafford wrote:
> Matteo Croce <technoboy85@...> writes:
> > and here there are patches for the radiotap parser, mac80211, tcpdump
> > and wireshark:
> > 
> > http://teknoraver.net/software/radiotap_mcs/
> 
> What version of Wireshark is this patch for? I tried to apply it to 1.2.5 from
> http://anonsvn.wireshark.org/viewvc/releases/wireshark-1.2.5/, but the files
> from your patch: Index:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4421

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: MCS field: RFA

[Roberto Riggio]

Matteo Croce <technoboy85@...> writes:

> 
> Hi,

Hi

> the MCS filed is in the suggested fields since about a month, now I
> request its approval.
> 
> Here is the draft of the field: http://www.radiotap.org/suggested-fields/MCS
> 
> and here there are patches for the radiotap parser, mac80211, tcpdump
> and wireshark:
> 
> http://teknoraver.net/software/radiotap_mcs/

do you have an updated version of your patch for the current (or a recent) 
compat wireless?

> Cheers,
> Matteo Croce

Roberto

Re: MCS field: RFA

[Johannes Berg]

On Mon, 2011-04-18 at 09:49 +0000, Roberto Riggio wrote:

> > Here is the draft of the field: http://www.radiotap.org/suggested-fields/MCS
> > 
> > and here there are patches for the radiotap parser, mac80211, tcpdump
> > and wireshark:
> > 
> > http://teknoraver.net/software/radiotap_mcs/
> 
> do you have an updated version of your patch for the current (or a recent) 
> compat wireless?

The MCS field was adopted and the Linux kernel supports it out of the
box now, along with wireshark trunk.

johannes

Re: MCS field: RFA

[Roberto Riggio]

Il 18/04/2011 12:01, Johannes Berg ha scritto:
> The MCS field was adopted and the Linux kernel supports it out of the
> box now, along with wireshark trunk.
Packet injection is not supported. I do have a patch for supporting it
at 11b/g/a rates, nut not for MCS rates. I will try to adapt Matteo's patch
> johannes
R.

Re: MCS field: RFA

[Roberto Riggio]

Il 18/04/2011 16:11, Matteo Croce ha scritto:
>
> BTW I'm working on refreshing this patch against latest compat-wireless
>
That would be great. I can test it on a few ath9k cards with click.

R.

-- 
--------------------------------------------------------
Roberto Riggio, Ph.D.
CREATE-NET
Network&  Security Solutions for Pervasive Computing Systems (iNSPIRE)
Senior Researcher
Via alla Cascata 56/D - 38123 Povo Trento (Italy)
e-mail: roberto.riggio-2TmCWn7/4sHOQU1ULcgDhA@public.gmane.org
Tel: (+39) 0461 408400 - interno/extension 708
Fax: (+39) 0461 421157
www.create-net.org/~rriggio
--------------------------------------------------------

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited according to
the Italian Law 196/2003 of the Legislature. If you received this in
error, please contact the sender and delete the material from any
computer.

Le informazioni contenute in questo messaggio di posta elettronica e nei
file allegati sono da considerarsi strettamente riservate. Il loro
utilizzo e' consentito esclusivamente al destinatario del messaggio, per
le finalita' indicate nel messaggio stesso. Qualora riceveste questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla cancellazione del
messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,
od utilizzarlo per finalita' diverse, costituisce comportamento
contrario ai principi dettati dal D. Lgs. 196/2003.

Re: MCS field: RFA

[Matteo Croce]

This patch allows to set the tx rate and retries when injecting,
and report correct MCS information on received frames.

Signed-off-by: Matteo Croce <matteo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>

--- a/net/mac80211/tx.c	2011-04-18 15:30:13.540573589 +0200
+++ b/net/mac80211/tx.c	2011-04-19 16:17:19.072552828 +0200
@@ -1091,6 +1091,44 @@
 				tx->flags |= IEEE80211_TX_FRAGMENTED;
 			break;

+		case IEEE80211_RADIOTAP_RATE: {
+			info->control.rates[0].idx = 0;
+			if (*iterator.this_arg) {
+				int i;
+				for (i = 0; i < sband->n_bitrates; i++)
+					if (sband->bitrates[i].bitrate ==
+						*iterator.this_arg * 5) {
+						info->control.rates[0].idx = i;
+						break;
+					}
+			}
+			info->control.rates[0].flags = 0;
+			info->control.rates[1].idx = -1;
+			info->control.rates[2].idx = -1;
+			info->control.rates[3].idx = -1;
+			info->control.rates[4].idx = -1;
+			break;
+		}
+
+		case IEEE80211_RADIOTAP_DATA_RETRIES:
+			info->control.rates[0].count = *iterator.this_arg;
+			break;
+
+		case IEEE80211_RADIOTAP_MCS: {
+			u8 flags = iterator.this_arg[1];
+			u8 mcs = iterator.this_arg[2];
+			info->control.rates[0].idx = mcs;
+			info->control.rates[0].flags |=
+				IEEE80211_TX_RC_MCS;
+			if (flags & IEEE80211_RADIOTAP_MCS_BW_40)
+				info->control.rates[0].flags |=
+				IEEE80211_TX_RC_40_MHZ_WIDTH;
+			if (flags & IEEE80211_RADIOTAP_MCS_SGI)
+				info->control.rates[0].flags |=
+				IEEE80211_TX_RC_SHORT_GI;
+			break;
+		}
+
 		/*
 		 * Please update the file
 		 * Documentation/networking/mac80211-injection.txt
--- a/net/mac80211/ieee80211_i.h	2011-04-18 15:30:13.532573589 +0200
+++ b/net/mac80211/ieee80211_i.h	2011-04-18 17:06:47.904572241 +0200
@@ -1196,6 +1196,10 @@
 	u8 padding_for_rate;
 	__le16 tx_flags;
 	u8 data_retries;
+	/*HT info*/
+	u8 ht_known;
+	u8 ht_flag;
+	u8 ht_mcs;
 } __packed;


--- a/net/mac80211/status.c	2011-04-18 15:30:13.548573589 +0200
+++ b/net/mac80211/status.c	2011-04-18 17:23:40.560572005 +0200
@@ -405,6 +405,19 @@
 	    !(info->status.rates[0].flags & IEEE80211_TX_RC_MCS))
 		rthdr->rate = sband->bitrates[
 				info->status.rates[0].idx].bitrate / 5;
+	/* HT rates */
+	if (info->status.rates[0].flags & IEEE80211_TX_RC_MCS) {
+		rthdr->hdr.it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
+		rthdr->rate = 0;
+		rthdr->ht_known =	IEEE80211_RADIOTAP_MCS_HAVE_BW |
+					IEEE80211_RADIOTAP_MCS_HAVE_MCS |
+					IEEE80211_RADIOTAP_MCS_HAVE_GI;
+		rthdr->ht_mcs = info->status.rates[0].idx;
+		if (info->status.rates[0].flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
+			rthdr->ht_flag |= IEEE80211_RADIOTAP_MCS_BW_40;
+		if (info->status.rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
+			rthdr->ht_flag |= IEEE80211_RADIOTAP_MCS_SGI;
+	}

 	/* for now report the total retry_count */
 	rthdr->data_retries = retry_count;
--- a/net/wireless/radiotap.c	2011-04-18 15:30:13.524573589 +0200
+++ b/net/wireless/radiotap.c	2011-04-18 16:11:36.044573011 +0200
@@ -40,6 +40,7 @@
 	[IEEE80211_RADIOTAP_TX_FLAGS] = { .align = 2, .size = 2, },
 	[IEEE80211_RADIOTAP_RTS_RETRIES] = { .align = 1, .size = 1, },
 	[IEEE80211_RADIOTAP_DATA_RETRIES] = { .align = 1, .size = 1, },
+	[IEEE80211_RADIOTAP_MCS] = { .align = 1, .size = 3, },
 	/*
 	 * add more here as they are defined in radiotap.h
 	 */

Re: MCS field: RFA

[Roberto Riggio]

Il 21/04/2011 17:04, Matteo Croce ha scritto:
> --- a/net/mac80211/ieee80211_i.h	2011-04-18 15:30:13.532573589 +0200
> +++ b/net/mac80211/ieee80211_i.h	2011-04-18 17:06:47.904572241 +0200
> @@ -1196,6 +1196,10 @@
>   	u8 padding_for_rate;
>   	__le16 tx_flags;
>   	u8 data_retries;
> +	/*HT info*/
> +	u8 ht_known;
> +	u8 ht_flag;
> +	u8 ht_mcs;
>   } __packed;
This generates this compile time error:

make[4]: Entering directory 
`/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/linux-2.6.37.6'
   CC [M]  
/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/net/mac80211/main.o
/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/net/mac80211/main.c: 
In function 'ieee80211_register_hw':
/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/net/mac80211/main.c:870:2: 
error: negative width in bit-field '<anonymous>'
make[6]: *** 
[/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/net/mac80211/main.o] 
Error 1
make[5]: *** 
[/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/net/mac80211] 
Error 2
make[4]: *** 
[_module_/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06] 
Error 2
make[4]: Leaving directory 
`/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/linux-2.6.37.6'
make[3]: *** [modules] Error 2
make[3]: Leaving directory 
`/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06'
make[2]: *** 
[/home/rriggio/src/wing/staging/kamikaze-trunk-26524/build_dir/linux-ixp4xx_wing/compat-wireless-2011-04-06/.built] 
Error 2
make[2]: Leaving directory 
`/home/rriggio/src/wing/staging/kamikaze-trunk-26524/package/mac80211'
make[1]: *** [package/mac80211/install] Error 2
make[1]: Leaving directory 
`/home/rriggio/src/wing/staging/kamikaze-trunk-26524'
make: *** [package/mac80211/install] Error 2

Re: MCS field: RFA

[Bill Stafford]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Aug 09, 2010, at 05:10 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
I've put a modified proposal here:
http://www.radiotap.org/suggested-fields/MCS-proposal2

I also added some a-MPDU status bits. They might not quite belong to
HT/MCS only, but they will typically be used with that and everything
else can indeed be masked out if really necessary

Thoughts?
 
I think the proposal2 looks great. The info mask is great for both tx specification and rx capture.

Adding single-bit fields has the advantage that they can be left out of
the header when, eg., you just know the MCS, but you don't know whether
it was 20 or 40 MHz (which, incidentally, is quite useless).
 
I think the mask for 20/40 is useful when using radiotap headers to do packet transmit. Some test setups only need the raw 802.11 format and possibly some HT modulation information, but may not care about 20/40. For instance, some test script may inject a packet for a STA to send to its associated AP and specify MCS 0 (for robustness) but leave the 20/40 info out so that the driver just sends at whatever the association has set up. Likewise, the test script may leave the shortGI/LDCP info unspecified.

-Bill


[-- Attachment #2.1: Type: text/html, Size: 2401 bytes --]