View Issue Details

IDProjectCategoryView StatusLast Update
0004220Kali Linux[All Projects] General Bugpublic2017-10-04 05:16
ReporterkimocoderAssigned Tosbrun 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2017.1 
Target Version2017.2Fixed in Version 
Summary0004220: carl9170 injection broken/missing
Descriptioncarl9170 chipset also have lost injection capabilities with both kernel v4.11 and v4.12. monitor mode still work though.

I also noticed from "airmon-ng --verbose" that "carl9170[mac80211]-1.9.6"
firmware v1.9.6 is used, while v1.9.9 is available.
Steps To Reproduceairmon-ng check kill
airmon-ng start wlan1
aireplay-ng -9 wlan1mon
Additional Informationhttps://wikidevi.com/wiki/Carl9170
https://wireless.wiki.kernel.org/en/users/drivers/carl9170

Activities

kimocoder

2017-09-03 19:43

reporter  

dookie

2017-09-04 15:04

administrator   ~0007244

Confirmed in Weekly 36. Extra logs attached.

dmesg-lsusb-messages.tar.gz (21,553 bytes)

rhertzog

2017-09-05 14:01

administrator   ~0007248

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

rhertzog

2017-09-08 05:20

administrator   ~0007260

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...

kimocoder

2017-09-08 14:35

reporter   ~0007273

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.

Mister_X

2017-09-10 21:22

reporter   ~0007281

@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.

kimocoder

2017-09-10 21:53

reporter   ~0007283

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.

kimocoder

2017-09-10 22:07

reporter   ~0007284

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

rhertzog

2017-09-11 08:52

administrator   ~0007286

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

rhertzog

2017-09-11 13:31

administrator   ~0007293

@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

dookie

2017-09-11 16:46

administrator   ~0007294

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.

2017.1.tar.gz (222,274 bytes)

kimocoder

2017-09-11 17:18

reporter   ~0007295

[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

dookie

2017-09-12 00:23

administrator   ~0007297

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:~#

rhertzog

2017-09-14 07:18

administrator   ~0007314

Last edited: 2017-09-14 07:18

View 2 revisions

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?

kimocoder

2017-09-14 07:21

reporter   ~0007315

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

dookie

2017-09-14 15:44

administrator   ~0007321

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,
...

kimocoder

2017-09-14 15:53

reporter   ~0007322

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

kimocoder

2017-09-14 19:53

reporter   ~0007327

No luck with none of this unfortunately :/

derosier

2017-09-15 18:30

reporter   ~0007338

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.

kimocoder

2017-09-15 18:45

reporter   ~0007339

Great. I've also notified johannes@sipsolutions.net about the issue.

Good to have you too onboard sir.

kimocoder

2017-09-21 14:24

reporter   ~0007389

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

derosier

2017-09-21 14:37

reporter   ~0007391

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.

derosier

2017-09-21 18:43

reporter   ~0007392

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.

kimocoder

2017-09-21 18:49

reporter   ~0007393

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

derosier

2017-09-25 18:19

reporter   ~0007409

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.

derosier

2017-09-29 18:07

reporter   ~0007421

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.

0001-wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch (2,528 bytes)
From c46a994dd78befbe94e66771db41c18351be2aae Mon Sep 17 00:00:00 2001
From: Steve deRosier <derosier@cal-sierra.com>
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 <derosier@cal-sierra.com>
---
 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

kimocoder

2017-09-29 18:32

reporter   ~0007422

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!

kimocoder

2017-09-30 07:25

reporter   ~0007427

@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

steev

2017-09-30 11:10

developer   ~0007429

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.

kimocoder

2017-09-30 11:15

reporter   ~0007430

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.

steev

2017-10-01 07:22

developer   ~0007432

@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).'

derosier

2017-10-01 14:17

reporter   ~0007434

@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.

steev

2017-10-01 22:46

developer   ~0007437

@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.

derosier

2017-10-01 22:54

reporter   ~0007438

@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

rhertzog

2017-10-02 14:15

administrator   ~0007447

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

kimocoder

2017-10-02 14:17

reporter   ~0007448

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

Awesome work on the patch. Thanks

sbrun

2017-10-04 05:16

manager   ~0007465

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

Issue History

Date Modified Username Field Change
2017-09-03 19:43 kimocoder New Issue
2017-09-03 19:43 kimocoder File Added: Screenshot from 2017-09-03 21-31-45.png
2017-09-04 15:04 dookie File Added: dmesg-lsusb-messages.tar.gz
2017-09-04 15:04 dookie Note Added: 0007244
2017-09-05 14:01 rhertzog Note Added: 0007248
2017-09-05 14:08 rhertzog Target Version => 2017.2
2017-09-08 05:20 rhertzog Note Added: 0007260
2017-09-08 14:35 kimocoder Note Added: 0007273
2017-09-10 21:22 Mister_X Note Added: 0007281
2017-09-10 21:53 kimocoder Note Added: 0007283
2017-09-10 22:07 kimocoder Note Added: 0007284
2017-09-11 08:52 rhertzog Note Added: 0007286
2017-09-11 08:53 rhertzog Assigned To => rhertzog
2017-09-11 08:53 rhertzog Status new => assigned
2017-09-11 13:31 rhertzog Note Added: 0007293
2017-09-11 16:46 dookie File Added: 2017.1.tar.gz
2017-09-11 16:46 dookie Note Added: 0007294
2017-09-11 17:18 kimocoder Note Added: 0007295
2017-09-12 00:23 dookie Note Added: 0007297
2017-09-14 07:18 rhertzog Note Added: 0007314
2017-09-14 07:18 rhertzog Note Edited: 0007314 View Revisions
2017-09-14 07:21 kimocoder Note Added: 0007315
2017-09-14 15:44 dookie Note Added: 0007321
2017-09-14 15:53 kimocoder Note Added: 0007322
2017-09-14 19:53 kimocoder Note Added: 0007327
2017-09-15 18:30 derosier Note Added: 0007338
2017-09-15 18:45 kimocoder Note Added: 0007339
2017-09-21 14:24 kimocoder Note Added: 0007389
2017-09-21 14:37 derosier Note Added: 0007391
2017-09-21 18:43 derosier Note Added: 0007392
2017-09-21 18:43 derosier Assigned To rhertzog => derosier
2017-09-21 18:49 kimocoder Note Added: 0007393
2017-09-25 18:19 derosier Note Added: 0007409
2017-09-29 18:07 derosier File Added: 0001-wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch
2017-09-29 18:07 derosier Note Added: 0007421
2017-09-29 18:32 kimocoder Note Added: 0007422
2017-09-30 07:25 kimocoder Note Added: 0007427
2017-09-30 11:10 steev Note Added: 0007429
2017-09-30 11:15 kimocoder Note Added: 0007430
2017-10-01 07:22 steev Note Added: 0007432
2017-10-01 14:17 derosier Note Added: 0007434
2017-10-01 22:46 steev Note Added: 0007437
2017-10-01 22:54 derosier Note Added: 0007438
2017-10-02 14:14 rhertzog Assigned To derosier => sbrun
2017-10-02 14:15 rhertzog Note Added: 0007447
2017-10-02 14:17 kimocoder Note Added: 0007448
2017-10-04 05:16 sbrun Status assigned => resolved
2017-10-04 05:16 sbrun Resolution open => fixed
2017-10-04 05:16 sbrun Note Added: 0007465