Created attachment 254773 [details] dmesg output with crashes My three Intel(R) Dual Band Wireless AC 8265 are crashing during sniffing in monitor mode, with tshark on a Linux machine. All there Intel 8265 are configured on 5180 MHz (CH36), 80 MHz bandwidth. It works for a indefinable time. That's all I can say for the moment. driver: iwlwifi version: 4.8.6 firmware-version: 27.455470.0
You have 3 devices on the same system sniffing on the same channel?
This could be related to this: https://bugzilla.kernel.org/show_bug.cgi?id=192691
Yes, that's correct. All 3 devices are installed in the same system, same radio channel.
OK... The use case seems surprising :) I'll open an internal ticket on the firmware team
Thanks for opening the ticket! Maybe I should explain my use case a bit: I'm trying to utilize the MU-MIMO options (mumimo-follow-mac, mumimo-groupid) while sniffing. Setting all 3 devices on the same radio channel, but with a different mumimo-groupid, hoping to get all the simultaneous streams (e.g. 3 clients, each 1x1 spatial stream capable) into one packet capture. Furthermore, you can increase the number of seen frames a bit, e.g. in a high density environment with a lot of traffic traveling the ether (SU-MIMO only). While one adapter did not correctly recognize a huge frame, another adapter was able to demodulate and decode it.
This is really interesting. People here will be interested to hear about your findings.
do you have the software that recomposes the single PCAP file based on all the inputs (in the scenario that does SU-MIMO only but that gets redundancy?
I can't tell you more right now, only what I'm trying to accomplish with the 3 devices, because it's not working stable (because of this bug) at the moment ;) I'm using wireshark/tshark only; there is no ready-made tool out there which does the trick for you. But of course, you need a little bit of post processing. This is done via tshark, python and so on. You'll have to dissect the pcap by interface id (frame.interface_id) and compare each frame with each other. Most tages/information should be identical, some things (arrival time, mac timestamp, mostly PHY/layer1 stuff) should differ and get left out for the comparison. It's kinda easy for data frames for example, because you can use the option to calculate a md5sum for each data payload (data.md5_hash) by wireshark itself.
We haven't written the script, but we were discussing using the timestamp to reorder things. The driver should now add the new radiotap timestamp field, and then you can find the same (e.g. beacon) frame in multiple captures to sync those timestamp fields, and after that you can get a good idea of what's going on.
Created attachment 254789 [details] Core24 with monitor Can you please record the debug data withe firmware attached as explained here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging Please take the time to read the privacy notice: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects
The data was sent privately and is now attached to the internal bug.
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?
Could you tell me how to do this and check it afterwards, please? I've tried editing the /etc/modprobe/iwlwifi.conf with "options amsdu_size=3" but failed miserably.
"options iwlwifi amsdu_size=3" should work I think
You can check later in sysfs: cat /sys/module/iwlwifi/parameters/amsdu_size
Well, thanks Johannes. ac-sniffer@acsniffer-ThinkCentre-M900:~/Downloads$ cat /etc/modprobe.d/iwlwifi.conf # /etc/modprobe.d/iwlwifi.conf # iwlwifi will dyamically load either iwldvm or iwlmvm depending on the # microcode file installed on the system. When removing iwlwifi, first # remove the iwl?vm module and then iwlwifi. remove iwlwifi \ (/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs /sbin/rmmod) \ && /sbin/modprobe -r mac80211 options iwlwifi amsdu_size=3 ac-sniffer@acsniffer-ThinkCentre-M900:~/Downloads$ cat /sys/module/iwlwifi/parameters/amsdu_size 3 Seems to run stable for me now. Did several packet capture (with 80 MHz 802.11ac packets flying around) in sniffer mode without any issue. No card crash, or reboot needed.
I documented this: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi?&#about_the_monitorsniffer_mode
Great that it works now! Thanks for testing. We will try to solve this at runtime, if at all possible. If not, we will have to hope that people read the section Emmanuel added on the Wiki.
*** Bug 195675 has been marked as a duplicate of this bug. ***
*** Bug 192691 has been marked as a duplicate of this bug. ***
I haven't had the chance to work on the automatic detection of monitor interfaces to change the amsdu size automatically. But it's in our internal TODO list. Closing this bug, since there is a solution. The automatic detection will land upstream at some point.