Packet injection only works on channels 1 to 11

[el-han]

I work in a research group that examines coexistence issues between wireless networks on the ISM bands. We are using a Netgear WNDA3200 stick, which features an AR7010+AR9280. We perform packet injection in order to simulate WiFi traffic and interfere with devices under test. However we were only able to perform packet injection on channels 1 to 11, despite the region was set to Germany. When using channel 12 or 13 or any channel on the 5 GHz band, the host programs report a successful packet transmission, however no packets are sent over the air.

Do you have any idea why packet injection is limited to channels 1 to 11? Is the region ignored in monitor mode? Is there any possibility to get injection working on higher channels?

Thanks in advance

Hannes

[olerem]

Hm... no idea. @erikarn do you know? blacklisted by eeprom?

[erikarn]

Weird. Um, can you see if ath9k is passing frames to the firmware?

A

On Nov 29, 2016 7:35 PM, "Oleksij Rempel" notifications@github.com wrote:

Hm... no idea. @erikarn https://github.com/erikarn do you know? blacklisted by eeprom?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/118#issuecomment-263774389, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7VWgJM1PDK09QcH5Vak8j_sta7-7ks5rDO8fgaJpZM4K96_f .

[rodizio1]

You can use this patch to get rid of all country restrictions: https://github.com/bortek/EZ-WifiBroadcast/blob/master/Patches/ez-wifibroadcast-1.4-kernel-4.4-patches.diff

Plese note, there are more changes to the drivers in the patch (changed medium access parameters, increased transmit power, changes to the fw loading mechanism, etc.) you may want to only use the portions that remove country restrictions.

[rfelten]

I can confirm this behavior, also on reg DE. Channel 1-11 works, on other channels no data is passed to the firmware. So I guess this is not an firmware issue rather than reg DB related.

@rodizio1 Thanks for your inspiring patches. Very helpful! If you plan to refactor/port them some day, you maybe want to turn them into a series of patches, each patch covering one topic. This would allow a better cherry picking :)

[olerem]

some or all of this changes should probably go mainline.

[el-han]

Thanks for all your help. @rodizio1 your patch allowed me to use packet injection in the 5 GHz band. Besides, the higher TX power is perfect for our purpose of causing WIFI interference inside of a shielded environment.

Hannes

[olerem]

Latest FW code is not able to set minimal rate for injected packages: https://github.com/qca/open-ath9k-htc-firmware/commit/6aca322ee0817b39da999d946224fa858ef551da

Testing is welcome.

[rodizio1]

Merry Christmas :)

Just tried it, iw ec086b1c7834 set bitrates legacy-2.4 18 says: command failed: Input/output error (-5)

dmesg output:

[  150.218875] ------------[ cut here ]------------
[  150.218961] WARNING: CPU: 2 PID: 739 at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0x178/0x188 [mac80211]()
[  150.218967] ec086b1c7834:  Failed check-sdata-in-driver check, flags: 0x0
[  150.218972] Modules linked in: arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 brcmfmac brcmutil cfg80211 evdev bcm2835_gpiomem smsc95xx usbnet mii
[  150.219010] CPU: 2 PID: 739 Comm: iw Not tainted 4.4.32-v7 #9
[  150.219015] Hardware name: BCM2709
[  150.219020] Backtrace: 
[  150.219040] [<80012940>] (dump_backtrace) from [<80012b38>] (show_stack+0x18/0x1c)
[  150.219046]  r6:60000013 r5:80541624 r4:00000000 r3:00000000
[  150.219063] [<80012b20>] (show_stack) from [<8021137c>] (dump_stack+0xac/0xcc)
[  150.219076] [<802112d0>] (dump_stack) from [<8001cc88>] (warn_slowpath_common+0x8c/0xbc)
[  150.219080]  r7:0000000c r6:7f13fa7c r5:00000009 r4:b56cbbb8
[  150.219096] [<8001cbfc>] (warn_slowpath_common) from [<8001ccf0>] (warn_slowpath_fmt+0x38/0x40)
[  150.219101]  r8:00000000 r7:b55e0428 r6:b55e042c r5:00000000 r4:7f16ff88
[  150.219157] [<8001ccbc>] (warn_slowpath_fmt) from [<7f13fa7c>] (ieee80211_set_bitrate_mask+0x178/0x188 [mac80211])
[  150.219162]  r3:b62da000 r2:7f16ff88
[  150.219169]  r4:b62da000
[  150.219259] [<7f13f904>] (ieee80211_set_bitrate_mask [mac80211]) from [<7f039bd0>] (nl80211_set_tx_bitrate_mask+0x37c/0x528 [cfg80211])
[  150.219264]  r10:00000001 r9:00000000 r8:00000000 r7:b55e0428 r6:b55e042c r5:00000000
[  150.219277]  r4:b30a0128
[  150.219323] [<7f039854>] (nl80211_set_tx_bitrate_mask [cfg80211]) from [<8038a12c>] (genl_rcv_msg+0x23c/0x3b4)
[  150.219328]  r10:b56cfc00 r9:00000014 r8:00000000 r7:7f05093c r6:b55e0414 r5:b56a7540
[  150.219341]  r4:7f052900
[  150.219351] [<80389ef0>] (genl_rcv_msg) from [<80389430>] (netlink_rcv_skb+0xa8/0xc4)
[  150.219356]  r10:b56a7540 r9:00000000 r8:00000000 r7:b56a7540 r6:b56a7540 r5:80389ef0
[  150.219369]  r4:b55e0400
[  150.219378] [<80389388>] (netlink_rcv_skb) from [<80389ee0>] (genl_rcv+0x2c/0x3c)
[  150.219383]  r6:b31cd400 r5:b56a7540 r4:8054fa04 r3:80389eb4
[  150.219398] [<80389eb4>] (genl_rcv) from [<80388dc8>] (netlink_unicast+0x184/0x20c)
[  150.219403]  r5:0000002c r4:b616e000
[  150.219414] [<80388c44>] (netlink_unicast) from [<8038924c>] (netlink_sendmsg+0x33c/0x350)
[  150.219419]  r8:00000000 r7:0000002c r6:00000000 r5:b31cd400 r4:b56cbf4c
[  150.219437] [<80388f10>] (netlink_sendmsg) from [<8034e5f4>] (sock_sendmsg+0x1c/0x2c)
[  150.219442]  r10:00000000 r9:b56cbe30 r8:00000000 r7:b5c6bb00 r6:00000000 r5:00000000
[  150.219455]  r4:b56cbf4c
[  150.219464] [<8034e5d8>] (sock_sendmsg) from [<8034ef4c>] (___sys_sendmsg+0x1d8/0x1e0)
[  150.219474] [<8034ed74>] (___sys_sendmsg) from [<8034fc14>] (__sys_sendmsg+0x44/0x74)
[  150.219478]  r9:b56ca000 r8:8000f904 r7:00000128 r6:7eb62b30 r5:00000000 r4:b5c6bb00
[  150.219497] [<8034fbd0>] (__sys_sendmsg) from [<8034fc54>] (SyS_sendmsg+0x10/0x14)
[  150.219502]  r6:000c4110 r5:000c51d0 r4:000c4080
[  150.219516] [<8034fc44>] (SyS_sendmsg) from [<8000f760>] (ret_fast_syscall+0x0/0x34)
[  150.219521] ---[ end trace 2fa1047266125702 ]---

Dongle is a TPLink 722N with AR9271 chipset, running Kernel 4.4.32 on a Raspberry Pi3.

[olerem]

beside, the configuration suggested by wifi videobraodcast tool didn't worked for me. Probably with similar error. So i use this script:

!/bin/bash

wlan="wlx00c0ca570d7d" mon="wlan0mon"

cd wifibroadcast

airmon-ng stop $mon ifconfig $wlan down ifconfig $wlan up iw $wlan set bitrates legacy-2.4 54 airmon-ng start $wlan 1 ifconfig $mon up echo start stream dd if=/dev/urandom bs=1M count=5000 | ./tx $mon

[psyborg55]

quick test of your patch:

disabling carrier sense made my alfa quickly stuck at 1Mbps tx rate and frozen link, sure i could reconnect easily but shortly after that it happens again.

reverted changes first in mac.h only - didn't help then reverted mac.c and htc_drv_main.c - it works fine just like before.

common_init.c - we can go here all the way from 2192 to 2732, the crap is ch14 and i'll explain later why. this should be fine i guess:

  CHAN2G(2467, 11), /* Channel 12 */
  CHAN2G(2472, 12), /* Channel 13 */
  CHAN2G(2484, 13), /* Channel 14 */
  CHAN2G(2487, 14), /* Channel XX */
  CHAN2G(2492, 15), /* Channel XX */

before messing with carrier sensing the card would reset in a loop and could not connect to the network, i knew this is because of bad and long usb cable so i reverted .max_power to 20 after that i could connect successfully so this means your txpower patch really does work. each time i tried to increase txpower the same way there was no difference, but one thing i missed was change in reg.c - i assume now this file is also important to patch.

about regd.c :

usually i #define ATH9K_2GHZ from 2312 to 2484 MHz and have all these channels available but i see you defined all channels beyond 14 as a ch14.

my card is now detected as abgn, under 2.4 mode i have channels 2192-2484 and to use channels above 2484 i have to select 5GHz mode (didn't try if it will work) but this kind of setup would prevent one from scanning whole 2GHz band at once.

further problems appear when you try to do this on latest hostapd releases, AP mode will not work, STA mode will work, monitor mode will not work (while STA is connected). there is hostapd version that allows negative channels without special patching hostapd-2015-03-25-1, but it still requires util.c patch, ieee802_11_common.c frequency patch and removing ch14 checks from hw_features.c

only thing i haven't tried are htc fw mods to allows different bitrates fw load.

[rodizio1]

olerem: Thanks, did some testing again. Setting the bitrates via iw only works when the interface is not in monitor mode and is not down. So I need to first bring the interface up (in managed mode) set the bitrate, then bring it down, set it to monitor mode and bring it up again.

This wouldn't be a problem, after all it's just some lines in a script. However, I have the feeling that this will make things more unstable. Things like bringing up or down interfaces or plugging/unplugging usb stuff is somehow flaky with the Pi and USB Atheros cards and leads to usb hanging and kernel crashes etc. sometimes. And then I've been fighting for every second to reduce boot-up time, I got it just under 10 seconds now until the videostream appears. I would rather not lose one or two seconds again with ifconfig up/down.

Would it be much work for you to make it possible to set it in monitor mode also?

psyborg55: The patch is geared towards injection and reception of packets with a fixed bitrate in monitor mode for use with my EZ-Wifibroadcast Raspberry image. I can't really tell what happens when using the cards as wifi client or hostapd access point, sorry. The txpower is set to the same value for all bitrates, which is probably not what you want considering that higher data rates need lower txpower to work properly. The bitrates I have tested are 802.11g 12,18,24,36mbit.

Disabling carrier sense is not a good idea, you will not gain anything but just interfere with other wifi networks around you. There is a reason it's not activated by default in the patch and that it prints a dmesg log line with more than one exclamation mark when it is activated ;) This is just for doing tests and veryfing changes in a shielded environment.

Regarding the channel numbers: It's not easy to get that right, it depends a lot on userspace programs also. Channel 14 is also a special case because it doesn't fit the "5Mhz-ladder" of the other channels. Since this patch is mainly intended for use with wifibroadcast anyway, I just decided to not bother with channel numbers at all and just set the channel with e.g. "iwconfig wlan0 channel 2462M"

[rodizio1]

Quoting myself:

This wouldn't be a problem, after all it's just some lines in a script. However, I have the feeling that this will make things more unstable. Things like bringing up or down interfaces or plugging/unplugging usb stuff is somehow flaky with the Pi and USB Atheros cards and leads to usb hanging and kernel crashes etc. sometimes.

Yep, it did :(

Only thing I changed was the script function that configures the interfaces. About every 2nd time or so the cards hang during that. Added some "sleep 1" lines between the iw commands, now it seems to be better.

Apart from that, I made a small program that injects packets for testing purposes via raw sockets. Now when I have configured the datarate via iw commands, injection doesn't work properly anymore, it injects for a few seconds, then stops, then injects again and so on. This is independent of the firmware used (either the older one or the newer one with support for userspace iw bitrate setting), it's just the iw set bitrates command that seems to cause this.

In contrast, the wifibroadcast tx program (which injects packets via pcap_inject) is not affected by this.

[olerem]

it feels like this part of mac80211 interface is not good tested or have not enough options for this work. Setting bitrate to monitore interaface seems to be not welcome by the code, i can image that normally it is not needed at all in this case. Bitrate command should influence the ratecontroller to enable or disable some values. If we do packet injection we avoid rate controller. In this case, the fact that injected packet are affected by rate controller, looks for me as buggy behavior. Probably proper fix would be to set rate on top of actual packet and let the internal ratecontroller use it. I never worked with packet injection interface. Do it allow to set rate for each packet?

[rodizio1]

Setting bitrate with iw while in monitor mode works with Ralink rt2800usb cards (without any patches).

Setting bitrate per packet would be even nicer, yes :)

I have this already working with Ralink rt2800usb cards and this kernel patch: https://github.com/bortek/EZ-WifiBroadcast/blob/master/Patches/mac80211-radiotap-bitrate_mcs_rtscts.linux-4.4.patch.

It works via a Radiotap header (www.radiotap.org) in-front of the IEEE802.11 frames that contains info on how to send the packet (i.e. tell the hardware to not wait for an ACK when injecting, etc.)

Telling the hardware to inject a frame with CTS-to-self protection also does not seem to work.