Mark Gannon | 24 Mar 20:35 2015

Packet Injection in Monitor Mode Sending Packets Twice

I'm currently troubleshooting a problem using the ath9k driver where by 
packets injected via libpcap are sent twice with slightly different radiotap 
headers.  The issue happens with different software injecting the packets.

The system is an up to date Gentoo box where uname -a shows:
Linux scooby 3.18.5-gentoo #1 SMP PREEMPT Wed Feb 4 16:54:06 EST 2015 x86_64 
AMD A6-3650 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux

lspci shows the card as:
02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter 
(rev 01)

In order to create the problem: 

1.  Load the driver:  modprobe ath9k debug=0x00000282
Note: The problem happens with or without the debug parameters 
2.  Create the monitor interface using: 
iw dev wlan0 interface add fish0 type monitor flags none
iw reg set US 
ifconfig fish0 up

3.  Download and build the packetspammer application from:
Note:  I edited Makefile to remove the -werror that was causing the make to 
4.  Start Wireshark listening to the fish0 interface.  
5.  Run packetspammer: ./packetspammer -d 1000000000000000000000000000 fish0
Note:  The long delay is to make the issue easier to see in the trace.

(Continue reading)

Michael Stahn | 23 Mar 21:03 2015

ath9k firmware / manipulating modulation


I've got one question regarding the possibilities when modificating the
firmware: Is it possible to manipulate the modulation via firmware eg
adjusting the QPSK when sending a symbol? Like sliding single symbols in
the Q/I plane by a fixed value apart from the intended location? The
following picture illustrates the modification:

If this is not feasable: Is there any wireless lan chip known having
open source firmware/software which is capable of doing so? I'm not
talking about SDR but *normal* wlan hw.

Adrian Chadd | 21 Mar 23:13 2015

Re: Power drain during suspend

Sujith - do you have access to the PCIe breakout stuff at QCA?
Something that we can use to measure the current draw of the NIC?

I haven't modified one of my TB boards to allow me to do that - I
probably should.


On 21 March 2015 at 02:01, Frank Zafka <kafkaesque1978 <at>> wrote:
>>Frank, can you load the driver with BTCOEX enabled and see if things improve ?
>>(sudo modprobe ath9k btcoex_enable=1)
> Didn't make any difference. Behaviour was no different. Thanks for the
> suggestion.
>>Was this card obtained from a different machine ?
> >From an earlier email, your machine is Acer ?
> I bought the card off ebay to access my 5ghz-wireless network. As I've
> said before, the card works fine during operation (excellent in fact),
> it's the suspend issue which is causing the problems.
> On Thu, Mar 19, 2015 at 7:51 AM, Frank Zafka <kafkaesque1978 <at>> wrote:
>> Thanks for the response Sujith. I am happy to help with testing any patches.
>> On Mon, Mar 16, 2015 at 8:29 PM, Frank Zafka <kafkaesque1978 <at>> wrote:
>>> It really is. It makes suspend useless since the laptop is waking
>>> up...and then shutting down (because of the low battery). I am loathed
>>> to give up and go back to the old abg card as the new n card is
>>> working perfectly in terms of speeds and connections during daily use.
(Continue reading)

Orozco | 18 Mar 21:36 2015

restarting ath9k_htc


I am working on a project where I need to be able to modify a wireless 
adapter's firmware. I'm trying to use the TP-LINK TL-WN722N with the 
ath9k_htc driver and firmware. I am trying to be able to quickly stop the  
transmission of packets then and just as quickly be able to restart the 
transmission. Ideally, I would be able to do a single stop/start in less 
time than it takes to transmit a packet.

								I am also trying to establish communications between the firmware 
and the driver so that the firmware can output some timing information. 

I would be very thankful if someone could tell me where would be a good 
place to start, and share any knowledge they have.



Risse Kilian | 16 Mar 13:24 2015

Multiple managed interfaces


I am looking for wifi cards that support multiple managed interfaces. 
As I understand there are some Atheros cards that support up to 2048 managed interfaces at the same time. 
I cannot find a list where it says how many interfaces and in what combination those can be used. 
I would be very thankful if someone could tell me how many managed interfaces the following chips support
(or if there exists a list with the specs where I can find that):

The first two are on the same card;



seb xper | 15 Mar 16:50 2015

init ath9k_htc device fails


I'm trying to get an external usb wireless stick working on my android phone using linux deploy. I've managed to compile the needed kernel module but initialising the device fails.

Could someone please point me in the right direction?

Thanks a lot.

lsusb output:
Bus 001 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg output:
[ 1230.872528] ath9k_common: Unknown symbol ath9k_hw_set_txpowerlimit (err 0)
[ 1266.442230] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 1266.679565] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[ 1266.934692] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.3
[ 1266.936035] ath: EEPROM regdomain: 0x809c
[ 1266.936096] ath: EEPROM indicates we should expect a country code
[ 1266.936157] ath: doing EEPROM country->regdmn map search
[ 1266.936218] ath: country maps to regdmn code: 0x52
[ 1266.936309] ath: Country alpha2 being used: CN
[ 1266.936370] ath: Regpair used: 0x52
[ 1266.936798] ------------[ cut here ]------------
[ 1266.937683] WARNING: at /home/seb/android/system/out/target/product/haida/obj/KERNEL_OBJ/modules/compat_wl12xx/net/wireless/reg.c:1279 wiphy_apply_custom_regulatory+0x130/0x188 [cfg80211]()
[ 1266.939605] Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath wl12xx_sdio(O) wl12xx(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: wl12xx_sdio]
[ 1266.940002] [<c0012cd8>] (unwind_backtrace+0x0/0xe0) from [<c008c44c>] (warn_slowpath_common+0x4c/0x64)
[ 1266.940185] [<c008c44c>] (warn_slowpath_common+0x4c/0x64) from [<c008c47c>] (warn_slowpath_null+0x18/0x1c)
[ 1266.940399] [<c008c47c>] (warn_slowpath_null+0x18/0x1c) from [<bf007ce8>] (wiphy_apply_custom_regulatory+0x130/0x188 [cfg80211])
[ 1266.940673] [<bf007ce8>] (wiphy_apply_custom_regulatory+0x130/0x188 [cfg80211]) from [<bf02377c>] (ath_regd_init+0x334/0x3c8 [ath])
[ 1266.940979] [<bf02377c>] (ath_regd_init+0x334/0x3c8 [ath]) from [<bf0ff4f4>] (ath9k_htc_probe_device+0x5fc/0x83c [ath9k_htc])
[ 1266.941284] [<bf0ff4f4>] (ath9k_htc_probe_device+0x5fc/0x83c [ath9k_htc]) from [<bf0f771c>] (ath9k_htc_hw_init+0x10/0x2c [ath9k_htc])
[ 1266.941589] [<bf0f771c>] (ath9k_htc_hw_init+0x10/0x2c [ath9k_htc]) from [<bf0f9030>] (ath9k_hif_usb_probe+0x338/0x374 [ath9k_htc])
[ 1266.941833] [<bf0f9030>] (ath9k_hif_usb_probe+0x338/0x374 [ath9k_htc]) from [<c038175c>] (usb_probe_interface+0x11c/0x198)
[ 1266.942016] [<c038175c>] (usb_probe_interface+0x11c/0x198) from [<c03165fc>] (driver_probe_device+0xb8/0x1fc)
[ 1266.942443] [<c03165fc>] (driver_probe_device+0xb8/0x1fc) from [<c03167a8>] (__driver_attach+0x68/0x8c)
[ 1266.942596] [<c03167a8>] (__driver_attach+0x68/0x8c) from [<c0314de8>] (bus_for_each_dev+0x48/0x80)
[ 1266.942749] [<c0314de8>] (bus_for_each_dev+0x48/0x80) from [<c0315d8c>] (bus_add_driver+0xd8/0x23c)
[ 1266.942901] [<c0315d8c>] (bus_add_driver+0xd8/0x23c) from [<c0316cac>] (driver_register+0x9c/0x120)
[ 1266.943054] [<c0316cac>] (driver_register+0x9c/0x120) from [<c03805c8>] (usb_register_driver+0x60/0x124)
[ 1266.943298] [<c03805c8>] (usb_register_driver+0x60/0x124) from [<bf10a008>] (init_module+0x8/0x2c [ath9k_htc])
[ 1266.943511] [<bf10a008>] (init_module+0x8/0x2c [ath9k_htc]) from [<c0008574>] (do_one_initcall+0x90/0x160)
[ 1266.943695] [<c0008574>] (do_one_initcall+0x90/0x160) from [<c00c3bd8>] (sys_init_module+0x1508/0x1694)
[ 1266.943878] [<c00c3bd8>] (sys_init_module+0x1508/0x1694) from [<c000dd40>] (ret_fast_syscall+0x0/0x30)
[ 1266.943969] ---[ end trace 0a7e2aee22e460a5 ]---
[ 1266.951690] ------------[ cut here ]------------
[ 1266.952575] WARNING: at /home/seb/android/system/out/target/product/haida/obj/KERNEL_OBJ/modules/compat_wl12xx/net/wireless/core.c:579 wiphy_register+0x4a8/0x518 [cfg80211]()
[ 1266.954437] Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath wl12xx_sdio(O) wl12xx(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: wl12xx_sdio]
[ 1266.954833] [<c0012cd8>] (unwind_backtrace+0x0/0xe0) from [<c008c44c>] (warn_slowpath_common+0x4c/0x64)
[ 1266.954986] [<c008c44c>] (warn_slowpath_common+0x4c/0x64) from [<c008c47c>] (warn_slowpath_null+0x18/0x1c)
[ 1266.955200] [<c008c47c>] (warn_slowpath_null+0x18/0x1c) from [<bf005170>] (wiphy_register+0x4a8/0x518 [cfg80211])
[ 1266.955596] [<bf005170>] (wiphy_register+0x4a8/0x518 [cfg80211]) from [<bf0295cc>] (ieee80211_register_hw+0x430/0x654 [mac80211])
[ 1266.955993] [<bf0295cc>] (ieee80211_register_hw+0x430/0x654 [mac80211]) from [<bf0ff564>] (ath9k_htc_probe_device+0x66c/0x83c [ath9k_htc])
[ 1266.956298] [<bf0ff564>] (ath9k_htc_probe_device+0x66c/0x83c [ath9k_htc]) from [<bf0f771c>] (ath9k_htc_hw_init+0x10/0x2c [ath9k_htc])
[ 1266.956756] [<bf0f771c>] (ath9k_htc_hw_init+0x10/0x2c [ath9k_htc]) from [<bf0f9030>] (ath9k_hif_usb_probe+0x338/0x374 [ath9k_htc])
[ 1266.957000] [<bf0f9030>] (ath9k_hif_usb_probe+0x338/0x374 [ath9k_htc]) from [<c038175c>] (usb_probe_interface+0x11c/0x198)
[ 1266.957183] [<c038175c>] (usb_probe_interface+0x11c/0x198) from [<c03165fc>] (driver_probe_device+0xb8/0x1fc)
[ 1266.957366] [<c03165fc>] (driver_probe_device+0xb8/0x1fc) from [<c03167a8>] (__driver_attach+0x68/0x8c)
[ 1266.957519] [<c03167a8>] (__driver_attach+0x68/0x8c) from [<c0314de8>] (bus_for_each_dev+0x48/0x80)
[ 1266.957672] [<c0314de8>] (bus_for_each_dev+0x48/0x80) from [<c0315d8c>] (bus_add_driver+0xd8/0x23c)
[ 1266.957824] [<c0315d8c>] (bus_add_driver+0xd8/0x23c) from [<c0316cac>] (driver_register+0x9c/0x120)
[ 1266.957977] [<c0316cac>] (driver_register+0x9c/0x120) from [<c03805c8>] (usb_register_driver+0x60/0x124)
[ 1266.958190] [<c03805c8>] (usb_register_driver+0x60/0x124) from [<bf10a008>] (init_module+0x8/0x2c [ath9k_htc])
[ 1266.958435] [<bf10a008>] (init_module+0x8/0x2c [ath9k_htc]) from [<c0008574>] (do_one_initcall+0x90/0x160)
[ 1266.958587] [<c0008574>] (do_one_initcall+0x90/0x160) from [<c00c3bd8>] (sys_init_module+0x1508/0x1694)
[ 1266.958770] [<c00c3bd8>] (sys_init_module+0x1508/0x1694) from [<c000dd40>] (ret_fast_syscall+0x0/0x30)
[ 1266.958862] ---[ end trace 0a7e2aee22e460a6 ]---
[ 1266.962249] Failed to initialize the device
[ 1266.970794] ath9k_htc: probe of 1-1:1.0 failed with error -22
ath9k-devel mailing list
ath9k-devel <at>
Sujith Manoharan | 15 Mar 09:12 2015

Re: Power drain during suspend

Frank Zafka wrote:
> 02:00.0 Network controller [0280]: Qualcomm Atheros AR9462 Wireless
> Network Adapter [168c:0034] (rev 01)
> Subsystem: Lenovo Device [17aa:3214]

This card supports WOWLAN and is a BT combo device. Maybe
ath9k is missing something in the suspend path.

Can you check if unloading both ath9k and ath3k before suspend
makes any difference ?

Oleksij Rempel | 15 Mar 07:52 2015

Fwd: some queries on open-ath9k f/w

This is probably better place for this question.

-------- Weitergeleitete Nachricht --------
Betreff: some queries on open-ath9k f/w
Datum: Wed, 4 Mar 2015 00:21:25 -0700
Von: Jithu Joseph <jithu83 <at>>
An: ath9k_htc_fw <at>


I want to play around with Link Layer Acks . I took a quick  looks at
the open sourced f/w code in github and couldn't find the Medium
Access code (wherein i expected to find some link layer ack setting).

Before getting into more specific queries , can someone tell whether
it is possible to do such low level stuff (given that we have access
to a an open-source f/w - or is it done fully in hardware and we don't
have a way to disable link layer acks , or is it done at the host
driver level  )

Ideally I am trying to implelemet something like this paper for a class

In this paper, they propose TCP/HACK (Hierarchical ACKnowledgment), a
system that applies cross-layer optimization to TCP traffic on WiFi
networks by carrying TCP ACKs within WiFi's link-layer
acknowledgments. By eliminating all medium acquisitions for TCP ACKs
in unidirectional TCP flows, TCP/HACK significantly improves medium
utilization, and thus significantly increases achievable capacity for
TCP workloads.


This is the code I looked into


Thanks and Regards

Jithu Joseph
+1 (385) 210 9875

ath9k_htc_fw mailing list
ath9k_htc_fw <at>

ath9k-devel mailing list
ath9k-devel <at>
Yahia Shabara | 15 Mar 07:19 2015

Acknowledgment handling in ath9k 80211g mode


I am working on an experiment that involves deciding packet transmissions depending on packet acknowledgements (single packet per transmission attempt).
I need to know whether I can handle acknowledgements in software without re-transmission attempts at the hardware level. i.e. For every packet transmission, I need the driver to check for the packet acknowledgement, if an ACK is received then the the driver may decide to transmit another packet, else it will decide to physically sense the channel.
This also means that packet transmissions without sensing may occur.

I wonder to what extent is this applicable. And what are the ways of implementing this if possible.

Thanks for your time.

Yahia Shabara.
ath9k-devel mailing list
ath9k-devel <at>
Frank Zafka | 14 Mar 10:04 2015

Power drain during suspend

Hello. Looking for some advice regarding a massive powerdrain during
suspend caused by the wifi card.

I have a new Atheros AR9462 connected to my n-wireless network.
Everything works fine. I put the computer into suspend (shut lid) and
everything goes as expected. However the battery is completely
emptying over night.

This behaviour is not correct. With the old wifi card (an Atheros abg
card) there was no battery drain. And there is also no battery drain
without a wifi card in.

I was wondering if this is a bug in the driver? I am running Arch
Linux. Any suggestions would be gratefully received. Thanks.

Arch forum thread:
Benjamin Berg | 13 Mar 14:33 2015

[PATCH] ath9k: Configure beacons for AP vif if this has not happened yet

Right now there is a bug where beaconing might not be enabled correctly
if the user has configuring multiple VIFs.
The issue surfaces if the userspace first creates the AP devices and
only then configures the first VIF (ath9k_bss_info_changed is called).
In this case the current ath9k_allow_beacon_config implementation will
not allow configuration as multiple AP VIFs are already present and
beaconing is never configured in the driver.

This issue was probably introduced back in 2012 by commit ef4ad6336
"ath9k: Cleanup beacon logic". The fix in this patch simply checks
whether beaconing has been configured yet (or configuration is scheduled)
and allows the configuration in that case. This works around the issue
here, but I have no idea whether it is a sane solution.

Signed-off-by: Benjamin Berg <benjamin <at>>
 drivers/net/wireless/ath/ath9k/beacon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index cb366ad..0eb83b8 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
 <at>  <at>  -522,7 +522,8  <at>  <at>  static bool ath9k_allow_beacon_config(struct ath_softc *sc,

 	if (sc->sc_ah->opmode == NL80211_IFTYPE_AP) {
 		if ((vif->type != NL80211_IFTYPE_AP) ||
-		    (sc->nbcnvifs > 1)) {
+		    test_bit(ATH_OP_BEACONS, &common->op_flags) ||
+		    (sc->ps_flags & PS_BEACON_SYNC)) {
 			ath_dbg(common, CONFIG,
 				"An AP interface is already present !\n");
 			return false;