2017-11-20 03:52 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004220Kali Linux[All Projects] General Bugpublic2017-10-04 05:16
Reporterkimocoder 
Assigned Tosbrun 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
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
Attached Files
  • png file icon Screenshot from 2017-09-03 21-31-45.png (128,729 bytes) 2017-09-03 19:43 -
    png file icon Screenshot from 2017-09-03 21-31-45.png (128,729 bytes) 2017-09-03 19:43 +
  • gz file icon dmesg-lsusb-messages.tar.gz (21,553 bytes) 2017-09-04 15:04
  • gz file icon 2017.1.tar.gz (222,274 bytes) 2017-09-11 16:46
  • patch file icon 0001-wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch (2,528 bytes) 2017-09-29 18:07 -
    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
    
    

-Relationships
+Relationships

-Notes

~0007244

dookie (administrator)

Confirmed in Weekly 36. Extra logs attached.

~0007248

rhertzog (administrator)

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

~0007260

rhertzog (administrator)

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

~0007273

kimocoder (reporter)

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.

~0007281

Mister_X (reporter)

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

~0007283

kimocoder (reporter)

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.

~0007284

kimocoder (reporter)

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

~0007286

rhertzog (administrator)

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

~0007293

rhertzog (administrator)

@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

~0007294

dookie (administrator)

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.

~0007295

kimocoder (reporter)

[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

~0007297

dookie (administrator)

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

~0007314

rhertzog (administrator)

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?

~0007315

kimocoder (reporter)

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

~0007321

dookie (administrator)

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

~0007322

kimocoder (reporter)

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

~0007327

kimocoder (reporter)

No luck with none of this unfortunately :/

~0007338

derosier (developer)

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.

~0007339

kimocoder (reporter)

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

Good to have you too onboard sir.

~0007389

kimocoder (reporter)

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

~0007391

derosier (developer)

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.

~0007392

derosier (developer)

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.

~0007393

kimocoder (reporter)

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

~0007409

derosier (developer)

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.

~0007421

derosier (developer)

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.

~0007422

kimocoder (reporter)

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!

~0007427

kimocoder (reporter)

@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

~0007429

threeway (developer)

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.

~0007430

kimocoder (reporter)

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.

~0007432

threeway (developer)

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

~0007434

derosier (developer)

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

~0007437

threeway (developer)

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

~0007438

derosier (developer)

@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

~0007447

rhertzog (administrator)

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

~0007448

kimocoder (reporter)

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

Awesome work on the patch. Thanks

~0007465

sbrun (manager)

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

-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 09:50 rhertzog Note Added: 0007288
2017-09-11 11:55 rhertzog Note Deleted: 0007288
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 threeway Note Added: 0007429
2017-09-30 11:15 kimocoder Note Added: 0007430
2017-10-01 07:22 threeway Note Added: 0007432
2017-10-01 14:17 derosier Note Added: 0007434
2017-10-01 22:46 threeway 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
+Issue History