* MCS field: RFA @ 2010-01-26 14:26 Matteo Croce [not found] ` <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Matteo Croce @ 2010-01-26 14:26 UTC (permalink / raw) To: Radiotap 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-01-26 17:47 ` David Young [not found] ` <20100126174728.GV1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: David Young @ 2010-01-26 17:47 UTC (permalink / raw) To: Radiotap 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <20100126174728.GV1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <20100126174728.GV1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> @ 2010-01-27 9:36 ` Johannes Berg [not found] ` <1264584965.25642.15.camel-YfaajirXv2244ywRPIzf9A@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Johannes Berg @ 2010-01-27 9:36 UTC (permalink / raw) To: David Young; +Cc: Radiotap [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <1264584965.25642.15.camel-YfaajirXv2244ywRPIzf9A@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <1264584965.25642.15.camel-YfaajirXv2244ywRPIzf9A@public.gmane.org> @ 2010-01-27 15:30 ` David Young [not found] ` <20100127153002.GC1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: David Young @ 2010-01-27 15:30 UTC (permalink / raw) To: Radiotap 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <20100127153002.GC1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <20100127153002.GC1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> @ 2010-01-27 15:32 ` Matteo Croce 2010-02-01 22:09 ` Bill Stafford 0 siblings, 1 reply; 27+ messages in thread From: Matteo Croce @ 2010-01-27 15:32 UTC (permalink / raw) To: Radiotap 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA 2010-01-27 15:32 ` Matteo Croce @ 2010-02-01 22:09 ` Bill Stafford [not found] ` <loom.20100201T230554-2-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Bill Stafford @ 2010-02-01 22:09 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <loom.20100201T230554-2-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <loom.20100201T230554-2-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> @ 2010-02-02 18:24 ` Johannes Berg 2010-02-02 19:54 ` David Young 1 sibling, 0 replies; 27+ messages in thread From: Johannes Berg @ 2010-02-02 18:24 UTC (permalink / raw) To: Bill Stafford; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA [not found] ` <loom.20100201T230554-2-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-02 18:24 ` Johannes Berg @ 2010-02-02 19:54 ` David Young [not found] ` <20100202195424.GE1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 1 sibling, 1 reply; 27+ messages in thread From: David Young @ 2010-02-02 19:54 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <20100202195424.GE1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <20100202195424.GE1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> @ 2010-02-03 5:24 ` Bill Stafford [not found] ` <C33B109A-9A6C-4931-8A69-5147A418E8B5-BUHhN+a2lJ4@public.gmane.org> 2010-03-25 23:50 ` David Young 1 sibling, 1 reply; 27+ messages in thread From: Bill Stafford @ 2010-02-03 5:24 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <C33B109A-9A6C-4931-8A69-5147A418E8B5-BUHhN+a2lJ4@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <C33B109A-9A6C-4931-8A69-5147A418E8B5-BUHhN+a2lJ4@public.gmane.org> @ 2010-02-04 1:11 ` Joshua (Shiwei) Zhao [not found] ` <d521a2311002031711i4293ae26i8c460aa3f41997e6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Joshua (Shiwei) Zhao @ 2010-02-04 1:11 UTC (permalink / raw) To: Bill Stafford; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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 > > ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <d521a2311002031711i4293ae26i8c460aa3f41997e6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <d521a2311002031711i4293ae26i8c460aa3f41997e6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-02-04 5:50 ` Bill Stafford [not found] ` <1F39C830-A521-456A-A5FA-2FC97914A74A-BUHhN+a2lJ4@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Bill Stafford @ 2010-02-04 5:50 UTC (permalink / raw) To: Joshua (Shiwei) Zhao; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <1F39C830-A521-456A-A5FA-2FC97914A74A-BUHhN+a2lJ4@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <1F39C830-A521-456A-A5FA-2FC97914A74A-BUHhN+a2lJ4@public.gmane.org> @ 2010-02-04 6:14 ` Joshua (Shiwei) Zhao 0 siblings, 0 replies; 27+ messages in thread From: Joshua (Shiwei) Zhao @ 2010-02-04 6:14 UTC (permalink / raw) To: Bill Stafford; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA [not found] ` <20100202195424.GE1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 2010-02-03 5:24 ` Bill Stafford @ 2010-03-25 23:50 ` David Young [not found] ` <20100325235000.GX414-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 1 sibling, 1 reply; 27+ messages in thread From: David Young @ 2010-03-25 23:50 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <20100325235000.GX414-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <20100325235000.GX414-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> @ 2010-03-26 4:57 ` Johannes Berg [not found] ` <1269579436.4581.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Johannes Berg @ 2010-03-26 4:57 UTC (permalink / raw) To: David Young; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <1269579436.4581.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <1269579436.4581.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2010-08-09 12:10 ` Johannes Berg 0 siblings, 0 replies; 27+ messages in thread From: Johannes Berg @ 2010-08-09 12:10 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA 2010-01-26 14:26 MCS field: RFA Matteo Croce [not found] ` <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-02-02 17:36 ` Bill Stafford [not found] ` <loom.20100202T174119-204-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-06 20:02 ` MCS field: RFA (wireshark patch) Bill Stafford 2011-04-18 9:49 ` MCS field: RFA Roberto Riggio 3 siblings, 1 reply; 27+ messages in thread From: Bill Stafford @ 2010-02-02 17:36 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <loom.20100202T174119-204-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <loom.20100202T174119-204-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> @ 2010-02-02 18:20 ` Johannes Berg 2010-02-02 18:24 ` David Young 1 sibling, 0 replies; 27+ messages in thread From: Johannes Berg @ 2010-02-02 18:20 UTC (permalink / raw) To: Bill Stafford; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA [not found] ` <loom.20100202T174119-204-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-02 18:20 ` Johannes Berg @ 2010-02-02 18:24 ` David Young 1 sibling, 0 replies; 27+ messages in thread From: David Young @ 2010-02-02 18:24 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA (wireshark patch) 2010-01-26 14:26 MCS field: RFA Matteo Croce [not found] ` <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-02-02 17:36 ` Bill Stafford @ 2010-02-06 20:02 ` Bill Stafford [not found] ` <loom.20100206T204036-824-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2011-04-18 9:49 ` MCS field: RFA Roberto Riggio 3 siblings, 1 reply; 27+ messages in thread From: Bill Stafford @ 2010-02-06 20:02 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <loom.20100206T204036-824-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>]
* Re: MCS field: RFA (wireshark patch) [not found] ` <loom.20100206T204036-824-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> @ 2010-02-06 20:31 ` Johannes Berg 0 siblings, 0 replies; 27+ messages in thread From: Johannes Berg @ 2010-02-06 20:31 UTC (permalink / raw) To: Bill Stafford; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA 2010-01-26 14:26 MCS field: RFA Matteo Croce ` (2 preceding siblings ...) 2010-02-06 20:02 ` MCS field: RFA (wireshark patch) Bill Stafford @ 2011-04-18 9:49 ` Roberto Riggio [not found] ` <loom.20110418T114722-716-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 3 siblings, 1 reply; 27+ messages in thread From: Roberto Riggio @ 2011-04-18 9:49 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <loom.20110418T114722-716-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <loom.20110418T114722-716-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> @ 2011-04-18 10:01 ` Johannes Berg [not found] ` <1303120873.3588.5.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Johannes Berg @ 2011-04-18 10:01 UTC (permalink / raw) To: Roberto Riggio; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <1303120873.3588.5.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <1303120873.3588.5.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2011-04-18 10:06 ` Roberto Riggio [not found] ` <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw@mail.gmail.com> 0 siblings, 1 reply; 27+ messages in thread From: Roberto Riggio @ 2011-04-18 10:06 UTC (permalink / raw) To: Johannes Berg; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw@mail.gmail.com>]
[parent not found: <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2011-04-20 13:12 ` Roberto Riggio [not found] ` <4DAEDBAB.5070100-2TmCWn7/4sHOQU1ULcgDhA@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Roberto Riggio @ 2011-04-20 13:12 UTC (permalink / raw) To: Matteo Croce; +Cc: Johannes Berg, radiotap-sUITvd46vNxg9hUCZPvPmw 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <4DAEDBAB.5070100-2TmCWn7/4sHOQU1ULcgDhA@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <4DAEDBAB.5070100-2TmCWn7/4sHOQU1ULcgDhA@public.gmane.org> @ 2011-04-21 15:04 ` Matteo Croce [not found] ` <BANLkTi=psWmOSJXDRQvGC2ABwYfR=8EFrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 27+ messages in thread From: Matteo Croce @ 2011-04-21 15:04 UTC (permalink / raw) To: Roberto Riggio; +Cc: Johannes Berg, radiotap-sUITvd46vNxg9hUCZPvPmw 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 */ ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <BANLkTi=psWmOSJXDRQvGC2ABwYfR=8EFrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: MCS field: RFA [not found] ` <BANLkTi=psWmOSJXDRQvGC2ABwYfR=8EFrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2011-04-22 7:07 ` Roberto Riggio 0 siblings, 0 replies; 27+ messages in thread From: Roberto Riggio @ 2011-04-22 7:07 UTC (permalink / raw) To: Matteo Croce; +Cc: Johannes Berg, radiotap-sUITvd46vNxg9hUCZPvPmw 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: MCS field: RFA @ 2010-08-30 21:21 Bill Stafford 0 siblings, 0 replies; 27+ messages in thread From: Bill Stafford @ 2010-08-30 21:21 UTC (permalink / raw) To: Johannes Berg; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-04-22 7:07 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-01-26 14:26 MCS field: RFA Matteo Croce [not found] ` <40101cc31001260626g4a47b7c6gde6f99e477e69ac9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-01-26 17:47 ` David Young [not found] ` <20100126174728.GV1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 2010-01-27 9:36 ` Johannes Berg [not found] ` <1264584965.25642.15.camel-YfaajirXv2244ywRPIzf9A@public.gmane.org> 2010-01-27 15:30 ` David Young [not found] ` <20100127153002.GC1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 2010-01-27 15:32 ` Matteo Croce 2010-02-01 22:09 ` Bill Stafford [not found] ` <loom.20100201T230554-2-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-02 18:24 ` Johannes Berg 2010-02-02 19:54 ` David Young [not found] ` <20100202195424.GE1060-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 2010-02-03 5:24 ` Bill Stafford [not found] ` <C33B109A-9A6C-4931-8A69-5147A418E8B5-BUHhN+a2lJ4@public.gmane.org> 2010-02-04 1:11 ` Joshua (Shiwei) Zhao [not found] ` <d521a2311002031711i4293ae26i8c460aa3f41997e6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-02-04 5:50 ` Bill Stafford [not found] ` <1F39C830-A521-456A-A5FA-2FC97914A74A-BUHhN+a2lJ4@public.gmane.org> 2010-02-04 6:14 ` Joshua (Shiwei) Zhao 2010-03-25 23:50 ` David Young [not found] ` <20100325235000.GX414-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org> 2010-03-26 4:57 ` Johannes Berg [not found] ` <1269579436.4581.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2010-08-09 12:10 ` Johannes Berg 2010-02-02 17:36 ` Bill Stafford [not found] ` <loom.20100202T174119-204-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-02 18:20 ` Johannes Berg 2010-02-02 18:24 ` David Young 2010-02-06 20:02 ` MCS field: RFA (wireshark patch) Bill Stafford [not found] ` <loom.20100206T204036-824-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2010-02-06 20:31 ` Johannes Berg 2011-04-18 9:49 ` MCS field: RFA Roberto Riggio [not found] ` <loom.20110418T114722-716-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org> 2011-04-18 10:01 ` Johannes Berg [not found] ` <1303120873.3588.5.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2011-04-18 10:06 ` Roberto Riggio [not found] ` <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw@mail.gmail.com> [not found] ` <BANLkTikV_YxYnFxjHrFE7XgYfi1T7J=3Tw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-04-20 13:12 ` Roberto Riggio [not found] ` <4DAEDBAB.5070100-2TmCWn7/4sHOQU1ULcgDhA@public.gmane.org> 2011-04-21 15:04 ` Matteo Croce [not found] ` <BANLkTi=psWmOSJXDRQvGC2ABwYfR=8EFrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-04-22 7:07 ` Roberto Riggio 2010-08-30 21:21 Bill Stafford
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).