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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
