kohler / click

The Click modular router: fast modular packet processing and analysis
Other
735 stars 322 forks source link

ath9k driver does not use the rate and power parameters defined by click elements #256

Open josemariasaldana opened 8 years ago

josemariasaldana commented 8 years ago

Hi, We are trying to control the rate and power of Wi-Fi transmission by using SetTXRate and SetTXPower elements respectively. We are using ath9k driver in a TP-Link Archer C7 (using the chipset Qualcomm Atheros QCA9558) We are operating in monitor mode, and the wireless card only generates frames at 1Mbps with constant transmission power. We use SetTXRate and SetTXPower elements, but it seems that the parameters we set with them are ignored.

rriggio commented 8 years ago

Hi Jose,

set tx power is pointless at the moment since the mac80211 stack ignores tx power field when parsing the radiotap header.

Regarding the TX rate I;m not sure why this is not working. However I've made quite a bit of changes to click in order to improve wifi support. If there is some interest from the main developers I would be quite interested in trying to bring my changes upstream.

R.

josemariasaldana commented 8 years ago

Thanks a lot. We are currently exploring if new versions of the ath9k driver are able to modify the power when in monitor mode. We are also exploring it with backports. If that worked, then adding it to Click would be a very good thing.

josemariasaldana commented 8 years ago

Hi Roberto,

Yesterday we ran an experiment with OpenWrt 15.05 in monitor mode: we run the command #iw dev mon0 set txpower 1800. After running the command, the power transmitted by the AP does get modified. The question is: does this mean that the mac80211 stack of OpenWrt 15.05 take into account tx power field when parsing the radiotap header?

rriggio commented 8 years ago

Hi,

yes of course if you use the command line you can change the tx power. However you cannot specify it on a frame-by-frame basis by using the tx power field. Openwrt 15.05 does not parse the tx power field (well to be precise the linux kernel used by owrt does not parse it).

R.

On Thu, Apr 21, 2016 at 3:57 PM, Jose Saldana notifications@github.com wrote:

Hi Roberto,

Yesterday we ran an experiment with OpenWrt 15.05 in monitor mode: we run the command #iw dev mon0 set txpower 1800. After running the command, the power transmitted by the AP does get modified. The question is: does this mean that the mac80211 stack of OpenWrt 15.05 take into account tx power field when parsing the radiotap header?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kohler/click/issues/256#issuecomment-212931558


Roberto Riggio, Ph.D. CREATE-NET Future Networks (FuN) Senior Researcher Via alla Cascata 56/D - 38123 Povo Trento (Italy) e-mail: roberto.riggio@create-net.org Tel: (+39) 0461 312481 Fax: (+39) 0461 421157

http://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.

josemariasaldana commented 8 years ago

Thanks a lot for the info! Jose

enridl commented 6 years ago

Hi Roberto,

I am having a similar issue with Click (and seems depending on the wifi card), since when I try to read RSSI/channel/noise values they do not correspond to what I see from wireshark. Accidentally, RSSI value read by click is in PRINT annotation and corresponds to channel first byte, when I see the radiotap header in wireshark:

FromDevice[2]
-> radiotap :: RadiotapDecap()
-> Print(-sniff-,PRINTANNO true, TIMESTAMP true)
-> FilterTX() // -> FilterPhyErr() -> PrintWifi(TIMESTAMP true) -> Idle; example 1:

wireshark: 0000 00 00 18 00 2e 40 00 a0 20 08 00 00 00 24 50 14 .....@.. ....$P. 0010 40 01 d4 00 00 00 d4 01 @.......

click: -sniff-: 1515750771.414411: 428 | 000000000000000000000000000000000120490700000000500000010800000000000000000000008019349e25320000 | 08620000 01005e00 00fb00c8 8b113f5d 30f77216 6bbfa06c

rssi: {dec:[ 80]|hex:[ 0x50]} | ESSID: | chan: 0| STA: 30-F7-72-16-6B-BF| BSSID: 00-C8-8B-11-3F-5D| : {data: frds}

example 2:

wireshark: 000018002e4000a02008000000026c09 a000da000000da010842000033330000 0001200cc83bc1d0080027412b53c038 5000006000000000aaaa0300000086dd 6000000000200001fe80000000000000 0a0027fffe412b53ff02000000000000 00000000000000013a00050200000000 8200fd83271000000000000000000000 000000000000000048fe1b1586b91b57

click: -sniff-: 1515747889.132775: 120 | 0000000000000000000000000000000001204907080000006c0000010800000000000000000000008019349e25320000 | 08420000 33330000 0001200c c83bc1d0 08002741 2b53c038

rssi: {dec:[ 108]|hex:[ 0x6c]} | ESSID: | chan: 0| STA: 08-00-27-41-2B-53| BSSID: 20-0C-C8-3B-C1-D0| : {data: frds}

Do you have any suggestions what might be getting wrong, or how to modify the click offsets/way of reading the radiotap header? I am afraid a hard mapping dependant on what I am seeing might still give wrong values for another card.

Best regards,