Re: Bandwidth monitoring

["David H. Lynch Jr." <dhlii@dlasys.net>]

>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