Created attachment 252011 [details] dmesg output I've recently aquired an intel 8260 wireless card, and I've noticed that while it's in monitor mode the firmware will crash. If I'm capturing packets with, for example, "tcpdump -i wlan0", while in monitor mode, the crash happens sporadically. It crashes on command, however, if I run a packet injection test with aireplay-ng with another usb wireless dongle I have. Using the command "aireplay-ng -9 -i wlan1 wlan0", with wlan0 being the Intel 8260 and wlan1 the usb dongle, I get: 10:52:29 Trying card-to-card injection... 10:52:29 Attack -0: OK 10:52:29 Attack -1 (open): OK 10:52:29 Attack -1 (psk): OK 10:52:29 Attack -2/-3/-4/-6: OK 10:52:34 Attack -5/-7: Failed With dmesg showing a firmware crash shortly after: iwlwifi 0000:06:00.0: Microcode SW error detected. Restarting 0x2000000. I'm using the latest firmware available at http://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git. dmesg output shows: iwlwifi 0000:06:00.0: firmware: direct-loading firmware iwlwifi-8000C-21.ucode iwlwifi 0000:06:00.0: loaded firmware version 21.373438.0 op_mode iwlmvm iwlwifi 0000:06:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 kernel version, as shown by "uname -a": Linux kali 4.6.0-kali1-amd64 #1 SMP Debian 4.6.4-1kali1 (2016-07-21) x86_64 GNU/Linux The firmware appears to be stable under normal usage, such as using it to connect to an AP and access the internet. The problems appear while it's in monitor mode.
Can you try it with our Core releases (choose Core24), as explained in our wiki[1]? Otherwise you can try to upgrade your kernel and use at least 4.8 and update your linux-firmware.git files (you need iwlwifi-8000C-22.ucode), which is the most up-to-date code we have in the mainline. [1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release
Created attachment 252211 [details] 4.8 dmesg I've upgraded my kernel to 4.8. After a few minutes of sniffing, the firmware crashed again. Attached is the dmesg output from that session. uname -a: Linux kali 4.8.0-kali2-amd64 #1 SMP Debian 4.8.15-1kali1 (2016-12-23) x86_64 GNU/Linux Should I still attempt installing the core driver on 4.8 or are those drivers for older kernels?
BTW - I also see that we get ASSERT 2B00 in the recovery flow.
Thanks, Ed! You could still try to use or Core24 release, since it can handle a much newer version of the firmware that is not supported in the mainline yet. Nevertheless, we'll investigate this further internally. I'll let you know about our findings. @Emmanuel, the recovery assert is indeed interesting too. Definitely something to look into as well.
Created attachment 252291 [details] dmesg with core24 Hi, I followed the instructions found in the link above to download and compile the core24 drivers. The compilation and installation itself was error free, but when I rebooted a few new errors showed up in dmesg (which is attached), and "iwconfig wlan0" outputs: wlan0 no wireless extensions. Of course, that means I can't use the wireless card at all with the core24 driver. Did I overlook something while compiling the driver?
You shouldn't use iwconfig, it's deprecated. The "no wireless extensions" means that you compiled Core24 without CPTCFG_CFG80211_WEXT in your config (which is okay, but it means you can't use iwconfig and other deprecated friends). Please use the iw tool[1] instead. As far as I can tell, Kali includes it in the kali-linux-wireless package. I can't see any harmful messages in the dmesg you provided. [ 18.895126] iwlwifi 0000:06:00.0: firmware: failed to load iwl-dbg-cfg.ini (-2) [ 18.895127] iwlwifi 0000:06:00.0: Direct firmware load for iwl-dbg-cfg.ini failed with error -2 This just means that a special debugging configuration file is not present. It's harmless. There is already people working in making this message (which just means the kernel didn't find a specific file) go away. [ 19.589495] iwlwifi 0000:06:00.0: firmware: direct-loading firmware iwlwifi-8000C-27.ucode [ 19.589504] iwlwifi 0000:06:00.0: capa flags index 3 larger than supported by driver [ 19.590169] iwlwifi 0000:06:00.0: loaded firmware version 27.455470.0 op_mode iwlmvm [...] [ 28.752021] iwlwifi 0000:06:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 [ 28.754060] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled [ 28.754313] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled [ 28.982027] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' Everything looks good here. You're loading iwlwifi-8000C-27.ucode, which is our latest release. [ 28.982348] thermal thermal_zone0: failed to read out thermal zone (-5) This is also harmless. The thermal framework is a bit too verbose IMHO. This just means that our device is not yet ready to provide thermal information (because it's not up and running yet). [1] https://wireless.wiki.kernel.org/en/users/documentation/iw
OK, thanks for the response, I didn't realize iwconfig was being phased out. I'm currently 2 hours into a sniffing session and there have been no crashes so far. I'll keep testing it and will update if something happens. In the meantime, I wanted to run a card-to-card injection test like I did in my original post to see if that still causes a crash on command. It appears that the realtek drivers that my usb wifi adapter uses need to be recompiled to make use of the mac80211 module from the core driver. Dmesg outputs several errors, all similar to this one: rtlwifi: disagrees about version of symbol ieee80211_beacon_get_tim rtlwifi: Unknown symbol ieee80211_beacon_get_tim (err -22) each complaining about a different symbol. I've never had to deal with this particular error before when compiling kernel modules, and I haven't been able to find an answer on google yet. I'm hoping someone here can shed some light on how I can resolve this so I can continue testing the core driver.
Great to hear that our core release seems to solve your problem! This mains that the fix is on its way to the mainline kernel. Regarding the realtek driver, unfortunately if you take our core release you won't be able to use other wireless drivers (such as rtlwifi). You will have to wait for us push the new code to the mainline (which will probably mean v4.11). Since we already have a fix for this bug on its way to the mainline, I'm closing this bug. Feel free to reopen it in case the problem reappears.
Created attachment 252381 [details] dmesg with core24 driver Sadly, I have gotten another crash, 4 hours into this test session. This isn't completely different than how it was before, I think the longest it has gone while just passively sniffing has been about 10 hours, and that was before I opened a bug report. Crashes typically happen much sooner than that, within half an hour or so, but I don't think 4 hours is unusual compared to the previous firmware I tried.
Okay, thanks for testing further and reporting back. I will open an internal report and assign it to be investigated further.
Created an internal bug report to track this. We'll come back to you as soon as we have more details.
We have another bug reported internally that seems to be the same. And it seems to happen when sniffing VHT frames and associations. Can you confirm whether you have VHT (i.e. 11ac) access points around?
Yeah, I can confirm that there are indeed a few 802.11ac access points within scanning range.
Thanks for confirming, we're debugging this and will come back to you when we have more information.
Like in bug 194599, it seems that this problem is because we are not using the correct size for the RX buffers. Could you try to load the iwlwifi module with amsdu_size=3 so we force the RB size to be 12K?
Haven't got any reply on this, so I'm assuming it's a duplicate and closing it. *** This bug has been marked as a duplicate of bug 194599 ***