Re: Bandwidth monitoring

Re: Bandwidth monitoring

[David H. Lynch Jr.]

>On Sunday, October 21, 2012 09:58:18 PM David H. Lynch Jr. wrote:
>> I am looking for an easy means to determine the characteristics of a
>> transmitted packet. 
>> Particularly whether it is HT20/HT40-/HT40+ I have used a variety of
>> sniffers, airodump, wireshark, ... and I can not seem to find
anything
>> that will tell me what I am after - or I do not know how to use them.
>differentiating between HT40+ and HT40- will be difficult to do with
>just one standard wifi device (should be possible with two though).

>If you use mac80211, have you setup your monitor channel by adding
>the HT20/HT40+/HT40- flag? 
># iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)


This is setting up to send on channel 1 HT40+ correct ?
I am already doing that I need to know if it is succeeding 
I am using Packettspammer to send with all the channel/frequency
radiotap headers removed.  an setting up using iw for what I want as
above.



>This might help.

>As for retrieving the information:
>If a HT20/HT40  frame was received, it should have a radiotap
>IEEE80211_RADIOTAP_MCS header element (on the monitor interface dump).
>In this element should provide the MCS and flags for 
> - BW40 (if false => HT20, if true => HT40+ or HT40- depending
>   on the channel configuration)
> - Short GI
> - Greenfield flag
> - (LDPC)

Wireshark appears to handle RadioTap - I am seeing lots of other flags
etc. but not BW40.

>But I don't know if any of this information is parsed by any of the
>current tools (depends on the version I guess). At least for wireshark
>you can always look at the raw hex dump of the package, so it should
>be there! The definitions of what RADIOTAP_MCS bit means what are in:
><include/net/ieee80211_radiotap.h>


Googling Radiotap produces lots of comments that suggest that Radiotap
headers - send and receive are not necescarily complete or accurate from
device to device - is that a reasonable conclusion ?



>Regards,
>	Chr

Thanks
--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bandwidth monitoring

[Christian Lamparter]

On Tuesday, October 23, 2012 08:58:39 PM David H. Lynch Jr. wrote:
>> On Sunday, October 21, 2012 09:58:18 PM David H. Lynch Jr. wrote:
>>> I am looking for an easy means to determine the characteristics of a
>>> transmitted packet. 
>>> Particularly whether it is HT20/HT40-/HT40+ I have used a variety of
>>> sniffers, airodump, wireshark, ... and I can not seem to find anything
>>> that will tell me what I am after - or I do not know how to use them.
>>differentiating between HT40+ and HT40- will be difficult to do with
>>just one standard wifi device (should be possible with two though).
>>
>>If you use mac80211, have you setup your monitor channel by adding
>>the HT20/HT40+/HT40- flag? 
>># iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)
> 
> This is setting up to send on channel 1 HT40+ correct ?
yes, I hope so.

> >As for retrieving the information:
> >If a HT20/HT40  frame was received, it should have a radiotap
> >IEEE80211_RADIOTAP_MCS header element (on the monitor interface dump).
> >In this element should provide the MCS and flags for 
> > - BW40 (if false => HT20, if true => HT40+ or HT40- depending
> >   on the channel configuration)
> > - Short GI
> > - Greenfield flag
> > - (LDPC)
> 
> Wireshark appears to handle RadioTap - I am seeing lots of other flags
> etc. but not BW40.
It depends on the version. Here's a screenshot
from wireshark 1.8.2: <http://imageshack.us/f/703/mcsinfo.png/>

>> But I don't know if any of this information is parsed by any of the
>> current tools (depends on the version I guess). At least for wireshark
>> you can always look at the raw hex dump of the package, so it should
>> be there! The definitions of what RADIOTAP_MCS bit means what are in:
>> <include/net/ieee80211_radiotap.h>
> 
> Googling Radiotap produces lots of comments that suggest that Radiotap
> headers - send and receive are not necescarily complete or accurate from
> device to device - is that a reasonable conclusion ?
Most mac80211 driver should report rx'ed MCS information.
At least ath9k, ath9k_htc, brcmsmac, carl9170, iwlagn, iwllegacy, mwl8k,
rt2800*, rtl8192* do.

What might not work is: injecting frames with MCS rates [no code
in ieee80211_parse_tx_radiotap for that?]... So maybe the issue
is indeed at the other end?

Regards,
	Chr

Re: Bandwidth monitoring

[David H. Lynch Jr.]

>From: Christian Lamparter <chunkeey@...>
>> But if I am am using iw to set monitor mode mode, channel, and
>> bandwidth, And using Raw sockets injection with a radiotap header
>> that has no frequency/channel/bandwidth information, 
>> I should then be able to receive that packet on another system
>> with an AR9170 and 1.8.2 Wireshark and the BW40 flag should be true?
>Ah now I see where the problem is.
>You see, the "40MHz bit" is part of the MCS rate meta info (aka flags).
>(See enum mac80211_rate_control_flags in include/net/mac80211.h)
RADIOTAP packet injection is not a manditory facet of my problem. 
I am only using it to inject a packet with know parameters so that I can
trace what is happening for the purposes of duplicating the behavior
either in firmware or in userspace. But before I can do so I need to see
the construction and environment changes needed to transmit an HT40
packet.

I would be happy with any other means of forcing the transmission of an
HT40 packet. RADIOTAP injection is just the only means I am aware of to
do so - and from what I am gathering not an effective one. 




>OffTopic:
>There is also a legacy duplicate flag IEEE80211_TX_RC_DUP_DATA that
>duplicates the 20MHz legacy packet in two 20MHz halves of a 40MHz
>channel. (The downside is that there's no dedicated RX_FLAG for
>that and this information is not available in the radiotap)
This might be sufficient - for the purposes of testing I do nto care
about the data in the packet. 






>The sending part is not. AFAICT you'll have to start by declaring
>and defining a new radiotap rate info element (IEEE80211_RADIOTAP_RATE
>can only handle the bit rate and that is not enough). Then you have
>to add a parser which translate the rate info in the radiotap header
>into mac80211 ieee80211_tx_rate and tell mac80211 to bypass rate_ctrl
>tx handler in this case so the info won't be overwritten again...
>And finally you'll have to add a header with this new rate info element
>into the radiotap header of all the frames you send through the raw
>monitor interface.

>A proof-of-concept should be easily doable within a day. But getting
>this
>new radiotap to be part of the spec will take longer ;)
with my level of Radiotap/mac80211/wifi knowledge this is much more than
a days work.

Any other ideas for forcing transmission of an HT40 packet ?
What If I omit radiotap and just send an ieee80211 raw packet ?

>> So I have been using airmon, wireshark, ....
>> But i need to be able to send and verify an HT40 packet by some
>>somewhat
>> normal means, to assure myself that my receiving end wireshark
>> hardware/driver/software combination can tell me what i need to
>know. 
>Well, you should be able to verify if your device picks up HT40 frames
>easily. All you need is any busy 11n network with a 11n AP and a 11n
>client. Just setup the receiver device (correct channel and HT40+/-
>setting) and start listening.
still not easy - no 80211n AP's just alot of AR9170's.
I guess I am going to be looking for a cheap 80211n AP. 



--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bandwidth monitoring

[Christian Lamparter]

On Monday, October 29, 2012 01:44:35 AM David H. Lynch Jr. wrote:
> I would be happy with any other means of forcing the transmission of an
> HT40 packet. RADIOTAP injection is just the only means I am aware of to
> do so - and from what I am gathering not an effective one.
Depends, hostapd uses it a lot. But it doesn't need to do any HT40
transmissions. I know that other people had similar issues as well,
but with ath9k. AFAICT, someone posted a patch on ath9k-devel which
made it possible to force the rate of outgoing frames, but you'll
have to google that.  
 
> > The sending part is not. AFAICT you'll have to start by declaring
> > and defining a new radiotap rate info element (IEEE80211_RADIOTAP_RATE
> > can only handle the bit rate and that is not enough). Then you have
> > to add a parser which translate the rate info in the radiotap header
> > into mac80211 ieee80211_tx_rate and tell mac80211 to bypass rate_ctrl
> > tx handler in this case so the info won't be overwritten again...
> > And finally you'll have to add a header with this new rate info element
> > into the radiotap header of all the frames you send through the raw
> > monitor interface.
> 
> > A proof-of-concept should be easily doable within a day. But getting
> > this new radiotap to be part of the spec will take longer ;)
> with my level of Radiotap/mac80211/wifi knowledge this is much more
> than a days work.
How do you know? The parser code is in ieee80211_parse_tx_radiotap and
all you would have to do is to extend it with another case and tell
mac80211 not to overwrite the rate in ieee80211_tx_h_rate_ctrl when
it was set by ieee80211_parse_tx_radiotap.
 
> Any other ideas for forcing transmission of an HT40 packet?
> What If I omit radiotap and just send an ieee80211 raw packet?
Sure, you can that. Just get a skb. Fill it with the data you
want to send and initialize the ieee80211_tx_control and
ieee80211_tx_info (in skb's cb) and call carl9170_op_tx.

If you want it to be done by the fw: Just reserve some space in 
ar9170_dma_memory and fill out the tx header carl9170_tx_superdesc
(header declarations and definitions are in include/shared/wlan.h)
and call wlan_tx_fw.

> >> So I have been using airmon, wireshark, ....
> >> But i need to be able to send and verify an HT40 packet by some
> >>somewhat
> >> normal means, to assure myself that my receiving end wireshark
> >> hardware/driver/software combination can tell me what i need to
> >know. 
> >Well, you should be able to verify if your device picks up HT40 frames
> >easily. All you need is any busy 11n network with a 11n AP and a 11n
> >client. Just setup the receiver device (correct channel and HT40+/-
> >setting) and start listening.
> still not easy - no 80211n AP's just alot of AR9170's.
> I guess I am going to be looking for a cheap 80211n AP. 

if you have two devices to spare you can setup one as AP and the other
as a client [this can be done on the same machine if you have network
namespaces].

AP:
 # hostapd hostapd.conf 

--- hostapd.conf ---
interface=wlanX
driver=nl80211
ssid=TESTN
hw_mode=g
channel=1
wmm_enabled=1
ieee80211n=1
ht_capab=[HT40+]
--- hostapd.conf ---


client:
 # iw dev wlanY connect TESTN

---
Then assign both AP and client ip addresses in the same subnet and
ping each other.

Regards,
	Chr

Re: Bandwidth monitoring

[David H. Lynch Jr.]

>From: Christian Lamparter
>>># iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)
>> 
>> This is setting up to send on channel 1 HT40+ correct ?
>yes, I hope so.

Thanks

>> Wireshark appears to handle RadioTap - I am seeing lots of other
>flags
>> etc. but not BW40.
>It depends on the version. Here's a screenshot
>from wireshark 1.8.2: <http://imageshack.us/f/703/mcsinfo.png/>
Thanks

>> Googling Radiotap produces lots of comments that suggest that
>>Radiotap
>> headers - send and receive are not necescarily complete or accurate
>>from
>> device to device - is that a reasonable conclusion ?
>Most mac80211 driver should report rx'ed MCS information.
>At least ath9k, ath9k_htc, brcmsmac, carl9170, iwlagn, iwllegacy,
>mwl8k,
>rt2800*, rtl8192* do
Using carl9170 so that should be OK.

>What might not work is: injecting frames with MCS rates [no code
>in ieee80211_parse_tx_radiotap for that?]... So maybe the issue
>is indeed at the other end?

Assuming Carl9170/AR9170's at both ends 
But if I am am using iw to set monitor mode mode, channel, and
bandwidth, 
And using Raw sockets injection with a radiotap header that has no
frequency/channel/bandwidth information, 
I should then be able to receive that packet on another system with an
AR9170 and 1.8.2 Wireshark and the BW40 flag should be true ?

I need to do something that involves sending HT40 packets in a
completely different context. But I do not have a spectrum analyzer to
confirm that i am actually sending what I want.
So I have been using airmon, wireshark, ....
But i need to be able to send and verify an HT40 packet by some somewhat
normal means, to assure myself that my receiving end wireshark
hardware/driver/software combination can tell me what i need to know. 




--
To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bandwidth monitoring

[Christian Lamparter]

On Sunday, October 28, 2012 04:37:47 PM David H. Lynch Jr. wrote:
> > From: Christian Lamparter
> >What might not work is: injecting frames with MCS rates [no code
> >in ieee80211_parse_tx_radiotap for that?]... So maybe the issue
> >is indeed at the other end?
> 
> Assuming Carl9170/AR9170's at both ends
Ah, any mac80211 device should do.

> But if I am am using iw to set monitor mode mode, channel, and
> bandwidth, And using Raw sockets injection with a radiotap header
> that has no frequency/channel/bandwidth information, 
> I should then be able to receive that packet on another system
> with an AR9170 and 1.8.2 Wireshark and the BW40 flag should be true?
Ah now I see where the problem is.
You see, the "40MHz bit" is part of the MCS rate meta info (aka flags).
(See enum mac80211_rate_control_flags in include/net/mac80211.h)

This stuff is usually set by the rate control algorithm. But because
you are injecting frames there's not alot of rate control and the frame
is usually send at the lowest possible data rate for the channel (usually
these are the 1MBit/6Mbit legacy rates and not HT20 or HT40 rates).
This is true for almost all mac80211 devices which don't feature a rate
control offload option in firmware (i.e.: ath9k_htc does have a firmware
rc and might do things differently).

OffTopic:
There is also a legacy duplicate flag IEEE80211_TX_RC_DUP_DATA that
duplicates the 20MHz legacy packet in two 20MHz halves of a 40MHz
channel. (The downside is that there's no dedicated RX_FLAG for
that and this information is not available in the radiotap)
 
> I need to do something that involves sending HT40 packets in a
> completely different context.
The receiving part should be handled by all of the mac80211 devices
I listed in the previous post out-of-the-box.

The sending part is not. AFAICT you'll have to start by declaring
and defining a new radiotap rate info element (IEEE80211_RADIOTAP_RATE
can only handle the bit rate and that is not enough). Then you have
to add a parser which translate the rate info in the radiotap header
into mac80211 ieee80211_tx_rate and tell mac80211 to bypass rate_ctrl
tx handler in this case so the info won't be overwritten again...
And finally you'll have to add a header with this new rate info element
into the radiotap header of all the frames you send through the raw
monitor interface.

A proof-of-concept should be easily doable within a day. But getting this
new radiotap to be part of the spec will take longer ;).

> But I do not have a spectrum analyzer to
> confirm that i am actually sending what I want.
I don't think you need a spectrum analyzer... unless of course 
it can also HT40 generate frames.

> So I have been using airmon, wireshark, ....
> But i need to be able to send and verify an HT40 packet by some somewhat
> normal means, to assure myself that my receiving end wireshark
> hardware/driver/software combination can tell me what i need to know. 
Well, you should be able to verify if your device picks up HT40 frames
easily. All you need is any busy 11n network with a 11n AP and a 11n
client. Just setup the receiver device (correct channel and HT40+/-
setting) and start listening.

Regards,
	Chr 

Bandwidth monitoring

[David H. Lynch Jr.]

I am looking for an easy means to determine the characteristics of a
transmitted packet. 
Particularly whether it is HT20/HT40-/HT40+
I have used a variety of sniffers, airodump, wireshark, ...
and I can not seem to find anything that will tell me what I am after -
or I do not know how to use them.
I am transmitting packets in monitor mode with specified frequencies and
parameters and i am trying to verify that I have sent what I intended
without getting a spectrum analyser.  

thanks

Re: Bandwidth monitoring

[Christian Lamparter]

On Sunday, October 21, 2012 09:58:18 PM David H. Lynch Jr. wrote:
> I am looking for an easy means to determine the characteristics of a
> transmitted packet. 
> Particularly whether it is HT20/HT40-/HT40+ I have used a variety of
> sniffers, airodump, wireshark, ... and I can not seem to find anything
> that will tell me what I am after - or I do not know how to use them.
differentiating between HT40+ and HT40- will be difficult to do with
just one standard wifi device (should be possible with two though).

If you use mac80211, have you setup your monitor channel by adding
the HT20/HT40+/HT40- flag? 
# iw dev wlanX set channel 1 HT40+ (or HT40-/HT20)

This might help.

As for retrieving the information:
If a HT20/HT40  frame was received, it should have a radiotap
IEEE80211_RADIOTAP_MCS header element (on the monitor interface dump).
In this element should provide the MCS and flags for 
 - BW40 (if false => HT20, if true => HT40+ or HT40- depending
   on the channel configuration)
 - Short GI
 - Greenfield flag
 - (LDPC)

But I don't know if any of this information is parsed by any of the
current tools (depends on the version I guess). At least for wireshark
you can always look at the raw hex dump of the package, so it should
be there! The definitions of what RADIOTAP_MCS bit means what are in:
<include/net/ieee80211_radiotap.h>

Regards,
	Chr