Created attachment 253541 [details] dmesg-output with one Intel 8265 crash When setting up a Intel 8265 to monitor mode via a simple bash script it crashes reproducible. Though, executing the commands individually it won't. I've got a trace-cmd report (with -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msgwhile), which I'd like to send compressed via a privately to a developer. ac-sniffer@acsniffer-ThinkCentre-M900:~$ ethtool -i wls3 | grep firmware firmware-version: 22.361476.0
Created attachment 253551 [details] dmesg-output with three Intel 8265 (crash)
Created attachment 253561 [details] Bash script
Does it work on channel 1 (freq = 2412)?
(In reply to Emmanuel Grumbach from comment #3) > Does it work on channel 1 (freq = 2412)? Yes, it does on freq 2412 with HT40+: no crash.
Please try with core24 from https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release You need to take the firmware and the driver. Thanks.
Thank you. Downloaded the firmware and moved it to /lib/firmware. Though compiling the Core24 driver aborts with errors on my PC. See the attached core24-build.txt
Created attachment 253651 [details] core24-build
Hm... Core24 won't work on such a recent kernel :( Do you have an older kernel installed on this system?
I've compiled kernel 4.8.6 from the sources, installed and rebooted, selected the 4.8.6 kernel on startup. Core24 won't compile though. You should have told me, which kernel I need ... ?
I just pushed the latest version of our Core24 release[1] and it compiles fine with v4.8 on my machine. Do you want to give it a try? In any case, I think we should probably add the min/max kernel version supported by each Core on our wiki... [1] http://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/?h=release/LinuxCore24
(In reply to Luca Coelho from comment #10) > I just pushed the latest version of our Core24 release[1] and it compiles > fine with v4.8 on my machine. Do you want to give it a try? Thank you. You are right - it compiled now without any errors. But the Intel 8265 still crashes. See the attached iwlwifi-8625-27-dmesg.log > In any case, I think we should probably add the min/max kernel version > supported by each Core on our wiki... Yes, good idea :)
Created attachment 253661 [details] iwlwifi-8625-27-dmesg.log
Addition: tried it again with channel 36 (freq 5180) - no problems, no crash?!
Can you try to check iw list?
Created attachment 253711 [details] iw list output As you can see in the iw list output, U-NII-2C channels are available (not marked as disabled). Tried it with Channel 104 again, see the dmesg output appended to the iw list output. Maybe it affects only U-NII-2C radio frequencies?
Can you please send the firmware dump that is generated by the firmware crash? Please see in [1] how to do that. In your case, no need for a special firmware. Please take the time to read the privacy notice here [2]. Thank you. [1] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#firmware_debugging [2] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects
I got the data. Thanks.
Haven't heard any news from you guys for a while. Did you come up with a thought how to solve this? I'm still getting bothered by this issue :/
Unfortunately, this bug is not my hands, but in the firmware team's hand. There isn't much I can from this point but being the bridge. I am still waiting for them.
The firmware team is telling me that the problem comes from the bandwidth. Can you please get the latest iw from git: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/ and do iw phy0 channels ? This will give us the allowed bandwidth. thanks.
Not need. Channel 104 can't be a control channel if the bandwidth is set to 80MHz but only the firmware enforces that. I'll share more details later.
Do I still need to provide the info, or will you share the details with us? :)
Sorry, I haven't found the time to dive into the channel table. If you have access to the 802.11 specification, you can look at Annex E to find the control channels that can take part in a 40MHz or 80MHz bonding. I'll try to find some time for this next week.
So I spent quite some time on this and: 104 can't be a central channel for a 80MHz channel width the spec defines that channel 106 can be a central channel, meaning: channel 106 maps to (5000 + 106 * 5) MHz = 5530MHz From what I see in the spec, channels 42 58 106 122 138 and 155 can be central channels for 80MHz bandwidth. On my device (which may have different tables than yours), I could open a sniffer using: set freq 5500 80 5530 set freq 5520 80 5530 set freq 5540 80 5530 set freq 5560 80 5530 When I try set freq 5520 80 5550 I get the same ASSERT as you. But 5520 80 5550 means: * central freq = 5550, which maps to channel 110 * control freq = 5520, which maps to channel 104 as written above this configuration is not allowed by the spec.
I am now closing this bug, I will continue to get mails notification on each one of your comments. You can re-open if you still think something needs to be changed in our behavior.
Thanks for you remarks on the channel selection for a 80 MHz 802.11ac radio channel! I will not re-open this case, but personally, I think the driver should intercept those non valid frequency configuriation, without an assertion. I'll try to find a workaround in my simple shell script, though.
You may want to take a look at bug 195299. We made the kernel more resilient. Look at the last patches I added there.