Confirmed in Weekly 36. Extra logs attached.

What should we do here? Is this a regression in our kernel patch? Or just a regular kernel regression?

Please I need some help here. If we want to make some progress on this issue, then I need to report it to the appropriate upstream developers (and I don't have the hardware to test the issue).

Can we narrow down the problem? Was it working with 4.9? Could someone bisect the kernel and find the commit that introduced the regression?

Was injection working on a plain upstream kernel or was our injection patch required for that card model?

How do you see that injection is not working? Does the "aireplay-ng -9 wlan1mon" command give back an error? Which one? Or are you seeing errors in the kernel logs? (I don't see anything in dookie's logs)

As for the firmware, it has not changed in a long time. I don't think the problem comes from the version mismatch. You can however try the latest firmware to download here:
http://linuxwireless.org/attachments/en/users/Drivers/carl9170/carl9170-1.fw-1.9.9
(install it as /lib/firmware/carl9170-1.fw and reboot or plug/unplug)

Note that this firmware version is newer compared to the reference tree tracked by Debian:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE#n2844

I tried to review some of the kernel commits done on drivers/net/wireless/ath/carl9170/ but there are no changes between 4.9 and 4.11. So if anything, it's probably related to changes in the core mac80211 code (net/mac80211/) but here we have way too many commits...

Hi there! The bug report was quickly made, not quite complete. I'll do some tests this weekend, so let me come back to the issue again. Thanks for the information given, will take a look.

@rhertzog, I did some quick tests. Aireplay-ng -9 tries to inject but doesn't get any response from any Access Point where an adapter with ath9k (same kernel) works just fine. So, what you'll see is always 0/30 when testing every access point with carl9170.

Aireplay-ng -9 will usually give you "Injection is working" if it is.

I haven't tested any different firmware or kernel than what was provided with Kali by default.

I know someone else who tested the newer firmware and he told me it doesn't change anything with 4.12.

Im looking into it at here too.
Does not work with kernel v4.13 either, but at this moment im going down to v4.9 and do the same there. As I may recall, it was working fine on v4.9 but I'll check anyway.

kernel bisecting im not too familiar with sadly but I probed kernel mailing lists + lkml yesterday and almost certain it must be in mac80211 as you pointed out, since nothing else really hasn't been touched.

Other drivers is also affected with the same problem, like the rt2800usb lost injection in kernel v4.12, but is working in v4.11 again. Other users reports around the web says other different ones lost injection capabilities, but this is something I can't confirm.

Will check lots of adapters tomorrow with different kernels to get more info too.

It's broken in Kali's v4.3.0 kernel also.. is is possible it's could have been broken from the firmware package (update 2017-04-04) then?? dmesg does not show any faults of any kind either

It's rather unlikely as the firmware did not change in that update:
http://git.kali.org/gitweb/?p=packages/firmware-nonfree.git;a=history;f=carl9170-1.fw;h=05c1f48b96f3e2f66e77c15b7e1a7f016949276f;hb=HEAD

@kimocoder, kernel bisecting is not very hard but it's very time-consuming as you must rebuild the kernel many times. But it gives very valuable information by pointing out the exact commit that broke the feature.

Have a look: https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html

This is also present in 2017.1, which was

Linux kali 4.9.0-kali3-amd64 0000001 SMP Debian 4.9.18-1kali1 (2017-04-04) x86_64 GNU/Linux

I've included logs from 2017.1, including syslog and messages, which contain some more info, such as the frequent "ieee80211 phy0: invalid plcp cck rate (0)" syslog messages.

Some general observations:

• Running a sniffer like airodump or kismet on a channel works fine and you will see both clients and APs
• Running a sniffer filtering on a particular WPA2 BSSID results in only seeing the AP. Clients never show up in the clients list
• Sniffing an AP with open auth, clients appear properly in aircrack and kismet.

[12569.518483] ieee80211 phy1: invalid plcp cck rate (4b).
[13077.527205] ieee80211 phy1: invalid plcp cck rate (0).
[13267.887634] ieee80211 phy1: invalid plcp cck rate (0).
+++ lots more of the zero (0) ones

I think i got rid of them when updating the firmware to v1.9.9 instead of using the v1.9.6 infact

For what it's worth, the identical issue is present in Debian sid:

root@debian:~# uname -a
Linux debian 4.12.0-1-amd64 0000001 SMP Debian 4.12.6-1 (2017-08-12) x86_64 GNU/Linux

root@debian:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid

root@debian:~# cat /etc/debian_version
buster/sid
root@debian:~#

Steev found out this change which is very old:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/carl9170?id=df1404650ccbfeb76a84f301f22316be0d00a864

Not sure if it's the one causing troubles but it might be worth trying. @kimocoder can you try to build a kernel with that patch reverted and test?

will be building this today. further info tba, thanks!

I tried building with this patch reverted yesterday and it didn't resolve the issue for me but that doesn't mean I did it all correctly. In addition to the two files in that patch, you'll find you also need to edit "include/net/mac80211.h" and re-add the IF_PROMISC_IN_BSS flag that was removed.

enum ieee80211_filter_flags {
FIF_PROMISC_IN_BSS = 1<<0,
FIF_ALLMULTI = 1<<1,
...

Done. Building kernel with reverted patch + additions added. Results will be posted.

No luck with none of this unfortunately :/

Hi kimocoder,

I'm looking at this now too. I've got to get setup to work on it, so give me a couple of days to dig in. Thanks.

Great. I've also notified [email protected] about the issue.

Good to have you too onboard sir.

Johannes Berg proposes testing with hwsim first, then take it to the kernel mailing lists. could someone do testing with hwsim?

https://wireless.wiki.kernel.org/en/users/drivers/mac80211_hwsim

Sure. I can try that today since I'm still waiting on my carl9170 card to show up (I've been assured it will show up today).

However - Mister_X mentioned it works fine on an ath9k but fails on the carl9170. That implies to me that the problem isn't in the mac80211 stack but in the carl9170 driver. My theory, which I'll be testing today, is something subtle changed in mac80211 and a few drivers didn't keep up. And it was a small enough feature that no one noticed until now.

In any case, I'll keep it updated here.

OK, here's my status at the moment:

tested with kernel v4.12.0-kali2

• injection is working fine with hwsim
• injection works fine with my rt2870
• injection doesn't work with an rtl 8192eu (but as it's a brand new chip to LInux, I'm not surprised)
• injection fails with carl9170

Also tested with kernel v4.9 stock kali 2017.01 and the carl9170 is still a fail. the rt2870 is still working.

Just so I'm not assuming anything I'll ask the stupid questions:

1. Did, in fact, did injection ever verifiably work with a carl9170 card?
2. And if so, does anyone know a version of the kernel or kali where injection did work on carl9170?

I'm asking 0000001 because I don't want to assume it did work and waste time looking for a kernel to bisect against.

I'm confident that I can fix it, but the answers to the questions above will change the approach.

Also, you're welcome to take it to the linux-wireless list, but as I'm likely the maintainer on the list who'd be looking at it/fixing it anyway, I'd say you already have our attention. :) Though it is always possible someone else might say something useful.

Great status report. well, it should be "working" according to this source

https://wireless.wiki.kernel.org/en/users/drivers/carl9170

Im currently probing through Google for more information too

OK for giggles I decided to see if injection has ever worked on this chip with Kali. I installed 2016.01 with a 4.3 kernel. Injection with aireplay is still a failure.

So, it either never worked with Kali or it was broken before kernel 4.3.

That said, I've got a good idea of why it fails. High-level concept why: it's MAC filtering the packets being returned. Other mac80211 chips work as does hwsim, so its something peculiar to this chipset. I expect it has to do with how promiscuous mode is being setup and expect it's a bug in the driver, though it's possible it's a firmware bug. I haven't dug into the specific issue (now that I know what it is) to determine where the fault lies yet.

Anyway, that's the update for the moment.

OK, I have a proposed solution. @kimocoder, could you please try my patch and see if it both solves your issue and works OK with other tools you need to use. In other words: check it doesn't cause any other unintended side effects.

My testing is basically to insert the device and then:
ifconfig wlan0 up
aireplay-ng -9 wlan0

And it works.

Now, the technical details, though this probably will be TLDR:

Injection on the carl9170 was actually always working. The packets that aireplay-ng was inserting were being transmitted. Specifically, it crafts specific Probe Request packets. The important thing to understand is that it does this with hand-crafted random sender MAC addresses. The APs do then send Probe Responses back to these random MAC addresses and aireplay-ng detects these and that's how it knows it gets the packet back and that injection is working.

The problem is that the Probe Response packets sent to these MAC addresses were not getting from the device hardware back up to the driver. Most packets were, but these specific ones were being filtered. Normally this is expected and doesn't cause issues, but in this particular case, it's a big problem. Unfortunately, no combination I could find of manipulating the filters would work to allow these particular packets to not get removed by the hardware.

While the problem is obvious (don't filter these packets), the solution wasn't. About five years ago, a patch went in to remove true sniffer mode and not use the relevant sniffer flag to the hardware. This went in to solve an issue with the hardware transmitting broken spurious ACK packets that would reduce the throughput on the channel. Hence I tried everything I could think of to just manipulate the MAC filtering without reverting the patch. Unfortunately, nothing I could find to do would work.

The attached patch adds the sniffer flag back in. I did make one change and left the AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER flag off. In my testing, adding the sniffer flag fixes our issue and the Probe Responses to random MACs do come back up to the driver to be processed, but keeping the rx control flag off removes the throughput stomping noise. I've tested this pretty throughly and at least with the 1.9.9 firmware it seems to work fine. The firmware I used is newer than what kali has by default and it's also newer than the original patch that fixed the spurious ack problem.

I don't think the patch I have will be upstreamable in it's current condition and so I'll send an RFC to linux-wireless and engage the other maintainers on what to do. But it should work for both testing purposes as well as Kali in general for now.

From c46a994dd78befbe94e66771db41c18351be2aae Mon Sep 17 00:00:00 2001
From: Steve deRosier <[email protected]>
Date: Fri, 29 Sep 2017 10:48:19 -0700
Subject: [PATCH] wireless: carl9170: Enable sniffer mode promisc flag to fix
 injection

The removal of the AR9170_MAC_SNIFFER_ENABLE_PROMISC flag to fix an issue
many years ago caused the AR9170 to not be able to pass probe response
packets with different MAC addresses back up to the driver. In general
operation, this doesn't matter, but in the case of packet injection with
aireplay-ng it is important. aireplay-ng specifically injects packets with
spoofed MAC addresses on the probe requests and looks for probe responses
back to those addresses. No other combination of filter flags seem to fix
this issue and so AR9170_MAC_SNIFFER_ENABLE is required to get these packets.

This was originally caused by commit e0509d3bdd7365d06c9bf570bf9f11 which
removed this flag in order to avoid spurious ack noise from the hardware.
In testing for this issue, keeping this flag but not restoring the
AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER flag on the rc_ctrl seems to solve this
issue, at least with the most current firmware v1.9.9.

Signed-off-by: Steve deRosier <[email protected]>
---
 drivers/net/wireless/ath/carl9170/mac.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c
index 7d4a72dc98db..c617e883f47a 100644
--- a/drivers/net/wireless/ath/carl9170/mac.c
+++ b/drivers/net/wireless/ath/carl9170/mac.c
@@ -309,6 +309,7 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
 	u32 rx_ctrl = AR9170_MAC_RX_CTRL_DEAGG |
 		      AR9170_MAC_RX_CTRL_SHORT_FILTER;
 	u32 sniffer = AR9170_MAC_SNIFFER_DEFAULTS;
+	u32 mac_ftf = AR9170_MAC_FTF_DEFAULTS;
 	int err = 0;
 
 	rcu_read_lock();
@@ -373,6 +374,9 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
 
 	if (ar->sniffer_enabled) {
 		enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE;
+		mac_ftf = AR9170_MAC_FTF_MONITOR;
+		sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
+		mac_addr = NULL;
 	}
 
 	err = carl9170_set_mac_reg(ar, AR9170_MAC_REG_MAC_ADDR_L, mac_addr);
@@ -384,6 +388,7 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
 		return err;
 
 	carl9170_regwrite_begin(ar);
+	carl9170_regwrite(AR9170_MAC_REG_FRAMETYPE_FILTER, mac_ftf);
 	carl9170_regwrite(AR9170_MAC_REG_SNIFFER, sniffer);
 	carl9170_regwrite(AR9170_MAC_REG_CAM_MODE, cam_mode);
 	carl9170_regwrite(AR9170_MAC_REG_ENCRYPTION, enc_mode);
-- 
2.14.1

This looks promising sir, let me try the patch this weekend, then I'll report back to you in a 24 hours time or so.

Seems you did alot of research on this, and for that I'll tap your shoulder for finding the needle in the (driver)stack.

Great work, thanks!

@derosier there you go!
Working like a charm :)

This actually fixes Kali support for injection on several adapters, like

• CradlePoint W211NU
• U-MEDIA WUB-710A
• Ubiquiti Networks SR71-USB
• Unex DNUA-81
• TP-LINK TL-WN821N v1
• TP-LINK TL-WN821N v2

This patch is confirmed working, great job sir.
This bug note should now absolutely be marked as RESOLVED

Can also confirm the patch works here.

I did get one message the first time I ran it of:

aireplay-ng -9 wlan0
ioctl(SIOCSIWMODE) failed: Device or resource busy
05:54:59 Trying broadcast probe requests...
05:54:59 Injection is working!
05:55:01 Found 3 APs

However, all subsequent runs did not show the SIOCSIWMODE message.

I did not get that SIOCSIWMODE, but the reproduce of what I did:

• Downloaded kernel v4.13.4 (Stable)
• Patched with the patch provided
• Buildt kernel with only that patch applied.

Worked great without any issues or error outputs at all.
of any kind.

@derosier do you know what kernel version this was initially changed in?

Also it may be nothing, but after letting that machine sit mostly idle (not sending any traffic through the carl9170 device which is a TP-LINK TL-WN821N v1 (according to lsusb) SMCWUSB-N2 (on the device) there is a lot of kernel output of

'[Timestamp] ieee80211 phy0: invalid plcp cck rate (0).'

@treeway,

The change is not upstream yet. The patch is based on a standard v4.13 kernel (Linus's, not Stable, though with this driver it makes no difference). I'm working on getting it upstream.

"plcp cck rate" is unrelated, it happens before this change and is a known issue. To my understanding it has no bearing on this bug.

@derosier i was meaning this comment "About five years ago, a patch went in to remove true sniffer mode and not use the relevant sniffer flag..." for the change going in (re: kernel version)

As the arm images do not always use an upstream kernel, I'll be looking to adapt this patch to their kernels, I was just wondering if you knew which version of the kernel has the initial change that it broke.

@threeway

Ah, sorry, I missunderstood.

Specifically, v3.8 should be the first mainline kernel that has it.

Here's the link to the patch on Linus's git:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e0509d3bdd7365d06c9bf570bf9f118cae6cbd58

Reassigned to Sophie so that she adds the patch in the next kernel upload.

Thanks to everyone involved in this, especially @derosier & @rhertzog

Awesome work on the patch. Thanks

A new kernel with the patch is now in kali-rolling: version 4.12.13-1kali2