kernel stack trace warning in sme.c #1988
Comments
|
A few questions:
|
|
|
It looks like a lookup of a BSS is failing. Run this before running iwconfig: and this afterwards: Then paste the results somewhere - a gist, pastebin etc., - or as a comment here if it isn't too large. |
|
For comparison, I ran a similar test on a standard Raspbian release running dhdpcd. In order to enable tracing before the wlan interface comes up I disabled dhcpcd from starting automatically: and rebooted. Then I ran: and this was the output: |
|
I was trying to ignore this harmless warning, but I am still seeing it on Linux 4.12 with ZeroW I have not tested other wifi devices to see if this is an upstream issue, or something specific to the RPI hardware. |
|
My laptop on Linux 4.10 (with an atheros wifi chip)connects to the same AP without the warning. Adding brcmfmac tracing gives: |
|
If I leave dhcpcd disabled. enable tracing and connect using Notice the rdev_connect message includes the bssid of the AP, but in your trace the corresponding ssid is all zeroes. I think this is what is causing the problem, but I can't explain the difference. |
|
I think that my bssid is showing as zeros because the AP is "hidden", but I cannot say that @herbertp has the same setup. All I can tell so far is that "cfg80211_get_bss" is returning early with a NULL, before reaching "trace_cfg80211_return_bss(&res->pub);", which may be due to the hidden ssid. |
|
Thanks for the hint - I'll experiment with hidden SSIDs. |
|
On Tue, May 23, 2017 at 09:59:37AM -0700, ED6E0F17 wrote:
I think that my bssid is showing as zeros because the AP is
"hidden", but I cannot say that @herbertp has the same setup.
Sorry for not getting back earlier ...
Yes, the AP is "hidden" here to, so the ESSID doesn't
show up in scans.
I will see if I can do some testing in the next few
days if it is still required.
Thanks,
Herbert
|
|
I've been experimenting with a NetGear AP, and even though I've disabled SSID broadcasting I still see the correct bssid value in the rdev_connect tracing. In a way that shouldn't be surprising because the WiFi stack must surely required a MAC address before it will consider connecting. In my current testing I've disabled dhcpcd and edited /etc/network/interfaces to look like this: I can then boot without wlan0 coming up, but running Run it with If you don't mind, can you run my test or something equivalent (@ED6E0F17 - perhaps just move the point where you enable tracing before the ifup) to capture more of the cfg80211 activity? |
|
I can use wpa_supplicant to connect to the AP without getting the WARN; I will do some more testing. |
|
I am not going to claim that this is a userspace issue, but wpa_supplicant seems to be doing something different than iw (and iwconfig from the initial report). There is a related issue that "iw wlan0 link" will fail if iw is used to connect to the hidden AP, but works perfectly well if wpa_supplicant makes the connection. As mentioned above, the obvious difference is the zeroed bssid, but also the auth type: |
|
Resolved with: giving: The underlying issue may be related to #1742 |
|
Interesting. Do the kernel backtraces also cease with your patch? |
|
I was waiting for a response to my question, but I would guess that answer would have been "Yes". The next step would be the creation of a proper patch with an explanation of the problem and why this is the correct solution, then it needs to go upstream. |
|
@ED6E0F17 We need a response really, to progress any further. |
|
What is the simplest way to test? Thanks in advance, |
|
I remember spending a lot of time looking at the code, and I didn`t get any closer to understanding it, but I think this is a symptom of a bug somewhere else in the wireless stack. I noticed that the Broadcom code was getting a lot of refactoring, but I am not actively testing new kernels to see if this issue has been fixed upstream. |
|
The main reason that I lost interest in this issue is that it does not affect wpa_supplicant, which is required for wpa2 - so this is a harmless warning that only affects hidden APs with wep or no encryption. |
|
@pelwell ISTR a recent issue with hidden SSID's, was that only on the 3B+? Perhaps related? |
|
I am still getting a stack trace on 4.14.38, but that is with old firmware: I need to update my initrd. |
|
I get the same result on 3B+ (Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04) |
|
[ 1986.561944] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) |
|
I believe that the brcmfmac driver is reading the SSID from the firmware in the function brcmf_get_assoc_ies(), and that may be where it is getting the zeroed-out SSID that it is later trying to compare to the Hidden SSID. |
|
Hi All, I'm doing the testing on Raspberry Pi Zero W, and still seeing the kernel tainting issue while turning wlan0 down and up "ifdown -a && rm -rf /var/run/wpa_supplicant/wlan0 && ifup -a" . I'm using latest Linux kernel from Buildroot "Linux buildroot 4.14.39" and wifi firmware version " Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f". Testing process: [ 1326.465528] ------------[ cut here ]------------ [ 1326.265587] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3) Once failed - it is getting fixed only after reboot of the board. Is this issue related rpi wifi firmware or the mainline kernel ? |
|
Any update on this warning ? |
|
Might be worth trying the latest bleeding edge 4.18 kernel to see if it helps. |
|
...which you can download with: |
|
Lots of changes in the driver since this issue was last visited. Please try the latest kernel code, and report back any issues. This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
|
I've been seeing a similar error on arm64 4.19.64-v8-g76b2727ef (and earlier 4.19 builds this past week) on a Raspberry Pi 4B. I'm just connecting to an access point, which has a somewhat low signal since this RPI4B is now in a metal case. Here is dmesg: https://paste.ubuntu.com/p/2b6YSz5XtX/ |
|
Same for me on Pi3B+.
Also, trace log: |
|
@DenyDarko I am also getting net/wireless/sme.c:752 __cfg80211_connect_result+0x3c0/0x410 [cfg80211] on a pi4 i just installed using wla0. i see the commands for the debug trace if i run this will a reboot of the pi wipe the trace or does it persist reboots (the pi4 is only wifi connected given its location). |
|
DenyDark and mine could be related to this #3318 as this is the same connect_result of 0x3c0/0x410 |
|
Event tracing enabled through sysfs is not persistent. You can normally set it persistently via cmdline.txt - use the |
|
@pelwell thanks for the info, i have tried disabling all features on my wifi equipment i thought could contribute (Unscheduled Automatic Power Save Delivery, fast roaming 80211r, multicast enhancements). My next test will be to disable CCMP encryption.... not sure what is left after that. When the unit is inside on 5ghz i have no issue, when the unit is outside and only able to make a 2.4ghz connection i have issues. What interesting is though the pi has no TCP/UDP connectivity I can still see it roaming between APs if i take the AP it is joined to offline, i even see that its IP seems to change. So my gut says this is related to wifi protocol and features itself. Any suggestions how to capture the issue in the trace without stringing a 100m CAT6 to outside in the rain :-) (which i will do, if i have to) |
|
Same issue for me, seems raspberry is not suitable for any interesting project. Apr 21 21:23:37 berryone kernel: [ 192.602922] ------------[ cut here ]------------ |
That's quite a broad statement. |
|
i have a thesis, i have yet to test fully I had similar issues with a old carrier thermostat where it would associate with the AP but never connect. After doing captures at the AP it was apparent that the thermostat didn't like certain types of broadcast DHCP offers from a win 2k19 dhcp server. So my thesis is there is an issue in some of the open source dhcp client stacks that are incompatible/have bug with certain types of offer packets. I still need to validate if the relay fixed my pi + wifi issues or not. This may not be your issue YMMV. |
|
[ 18.130122] WARNING: CPU: 2 PID: 37 at net/wireless/sme.c:1088 __cfg80211_disconnected+0x554/0x5a0 [cfg80211] |
|
Which network interfaces were active at the time this exception occurred? Have you tried disabling other devices such as the CAN bus interface? |
|
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 lsusb -v -D /dev/bus/usb/001/005 |
|
You're using an external RealTek WLAN adaptor, and with the downstream 8192cu driver. Aside from writing your own driver, that's about as unsupported as it gets. This is a different WARN to the original post, and it appears to be as the result of the device disconnecting (possibly forcibly), which would make this a symptom of a bigger problem - why is the adaptor disconnecting? If I had to guess, looking at the list of modules you have loaded, does the Pi have enough power to driver them all? Try with the WLAN adaptor on a powered hub. |
|
I think this ticket represent the same issue I have with a RPi4, it is a Yocto generated image with kernel version Here is the kernel trace I just finished testing the same driver and wifi device (DWA-181) on a RPi3 B+ but with kernel Hope this helps for something. |
|
looks like the same on my pi4 with kernel |
|
I'm having wifi trouble with my Raspberry Pi 0W, buster. The network problems are vague but everything seemed stable until a month or so ago following a "sudo apt upgrade". Sorry for being vague but at any rate, this problem is still active. This Pi (one of ~8 on my lan) seems to be the only one with this specific problem. I have occasional network issues with the other devices but not this particular problem. pi@mel:~ $ hostnamectl This is from /var/log/messages: Oct 1 08:33:37 mel kernel: [65827.404433] ------------[ cut here ]------------ |
|
new problem pi 3b+ 5.4.72-v7+ [ 18.737652] ------------[ cut here ]------------ |
|
after kernel upgrade 5.10.1-v7+ everything works fine, no error. It even started working WireGuard |
|
Raspberry PI4 @ 5.10.17-v7l+ #1403 Mar 11 20:17:23 gridbox kernel: [ 25.699064] ieee80211 phy0: brcmf_update_bss_info: wl dtim_assoc failed (-52) |
Always happens when I bring up wifi.
The text was updated successfully, but these errors were encountered: