2017-09-23 00:13 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004220Kali Linux[All Projects] General Bugpublic2017-09-21 18:49
Reporterkimocoder 
Assigned Toderosier 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
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

-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
+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
+Issue History