Description of problem: After upgrading to kernel 5.0.0-0.rc3.git0.1.fc30.x86_64 wifi network connection freezes on addrconf (netdev_up): ipv6: wlo1: link is not ready. Version-Release number of selected component (if applicable): Network manager 1.1.14.4-2.fc30 How reproducible: Every attempted connection Steps to Reproduce: 1. 2. 3. Actual results: Activatation of network connection failed. Expected results: Additional info: This new kernel is a debug kernel and therefore my Broadcom drivers would not compile. (As any code that uses gpl defines) In this case I just reboot and use a previous kernel that wifi was known to work. This time however neither of the 2 previous kernels would connect to wifi as in the past. They both would get to the dmesg ipv6 line and freeze. I added a line in /etc/default/grub, ipv6.disable=1 and rebuilt grub then rebooted. Still no connection. But the last line of dmesg was a rfkill line and not ipv6. This only indicates that the ipv6 was just the last output of dmesg and not necessarily where the code is failing. At this point I have no network and need to manually make a change that will fix this. Or, I can find a wired network and reinstall/downgrade packages. I have run Lshw -class network Lsusb Lspci Rfkill list all Dmesg | grep -i firmware Examined /var/log/Xorg.0.log And have not found any error statements. The wifi is set for dhcp ip4v automatic and ip6v automatic. The hotspot has WPA2 PSK security. I have checked the security phrase more than once. I am not getting any prompt for psssword, it just times out.
[SOLVED] Downgraded to nodebug kernel 5.0.0-0.rc4.git2.2.fc30.x86_64 Upgraded gcc 9.0.0.3 package with dependencies Downgraded wpa_supplicant package Ultimately it was wpa_supplicant that had the bug as others in Fedora land reported.
(In reply to Paul Lambert from comment #1) > [SOLVED] > > Downgraded to nodebug kernel 5.0.0-0.rc4.git2.2.fc30.x86_64 > Upgraded gcc 9.0.0.3 package with dependencies > Downgraded wpa_supplicant package > > Ultimately it was wpa_supplicant that had the bug as others in Fedora land > reported. Do you have any link to such bug reports about wpa_supplicant?
Try these links below. One stated downgrading wpa_supplicant and networking was restored. I did the same thing and got the same results. The wifi connection process using the newest package version was hanging on getting the IP address by DHCP based on my observations posted in journalctl. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919138 https://bbs.archlinux.org/viewtopic.php?pid=1830957
Lastest wpa_supplicant 1:2.7-4.fc30 distributed with kernel 5.0.0-0.rc5.git0.1.fc30.x86_64 is still broken. Downgraded to wpa_supplicant 1:2.7.1.fc29 to enable working wifi
(In reply to Paul Lambert from comment #4) > Lastest wpa_supplicant 1:2.7-4.fc30 distributed with kernel > 5.0.0-0.rc5.git0.1.fc30.x86_64 is still broken. Downgraded to > wpa_supplicant 1:2.7.1.fc29 to enable working wifi Can you please add '-dd' to OTHER_ARGS in /etc/sysconfig/wpa_supplicant, restart the wpa_supplicant service, try to connect with 2.7-4.fc30 and attach the output of 'journalctl -u wpa_supplicant -b'? Thanks.
I restarted NetworkManager a couple of times. Wifi is working. Feb 15 13:04:35 BRSINC-01Fed wpa_supplicant[937]: bgscan simple: Failed to enable signal strength monitoring Feb 15 13:04:43 BRSINC-01Fed wpa_supplicant[937]: wlo1: WPA: Group rekeying completed with 0a:d4:6a:6f:64:36 [GTK=CCMP] Feb 15 13:06:30 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-DISCONNECTED bssid=0a:d4:6a:6f:64:36 reason=3 locally_generated=1 Feb 15 13:06:30 BRSINC-01Fed wpa_supplicant[937]: nl80211: Was expecting local disconnect but got another disconnect event first Feb 15 13:06:30 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD Feb 15 13:06:30 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: wlo1: Trying to associate with 0a:d4:6a:6f:64:36 (SSID='G7 ThinQ_0444' freq=2437 MHz) Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: wlo1: Associated with 0a:d4:6a:6f:64:36 Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: wlo1: WPA: Key negotiation completed with 0a:d4:6a:6f:64:36 [PTK=CCMP GTK=CCMP] Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-CONNECTED - Connection to 0a:d4:6a:6f:64:36 completed [id=1 id_str=] Feb 15 13:06:37 BRSINC-01Fed wpa_supplicant[937]: bgscan simple: Failed to enable signal strength monitoring Feb 15 13:07:58 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-DISCONNECTED bssid=0a:d4:6a:6f:64:36 reason=3 locally_generated=1 Feb 15 13:07:58 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD Feb 15 13:07:58 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US Feb 15 13:07:58 BRSINC-01Fed wpa_supplicant[937]: wlo1: Reject scan trigger since one is already pending Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: wlo1: Trying to associate with 0a:d4:6a:6f:64:36 (SSID='G7 ThinQ_0444' freq=2437 MHz) Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: wlo1: Associated with 0a:d4:6a:6f:64:36 Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: wlo1: WPA: Key negotiation completed with 0a:d4:6a:6f:64:36 [PTK=CCMP GTK=CCMP] Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: wlo1: CTRL-EVENT-CONNECTED - Connection to 0a:d4:6a:6f:64:36 completed [id=2 id_str=] Feb 15 13:08:00 BRSINC-01Fed wpa_supplicant[937]: bgscan simple: Failed to enable signal strength monitoring
Created attachment 1535342 [details] journalctl output for wifi errors
This wpa_supplicant package bug is not yet resolved. I have collected journalctl output from various test combinations of kernel and wpa_supplicant versions. Though wpa_supplicant-2.7-4.fc30 worked on the previous kernel as soon as I upgraded to kernel 5.0.0-0.rc6.git1.2.fc30.x86_64 it did not with or without the added -dd. I downgraded the kernerl back to 4.20.7-200.fc29.x86_64 and neither wpa_supplicant 2.7-4.fc30 nor 1:2.7.1.fc29 would work. Currently, I am using kernel 5.0.0-0.rc6.git1.2.fc30.x86_64 with wpa_supplicant 1:2.7-1.fc29 and with OTHER_ARGS="-dd -s" in /etc/sysconfig/wpa_supplicant. The journalctl output attached file should pinpoint where this bug resides.
Hi, the problem is still here with wpa_supplicant 2.7-4.fc30. And downgrading wpa_supplicant to wpa_supplicant-1:2.6-17.fc29.x86_64 also worked. I have also found that the ArchLinux community has the same issue: https://bugs.archlinux.org/task/61119. Additional info: bcm4360 and the broadcom-wl-6.30.223.271-9.fc30. Kernel 5.0.6-300.fc30.x86_64. Please solve the bug or at least downgrade the package. A stable release of Fedora should not include a malfunctioning package.
Hi, the problem is present in the FC30 release I just installed. I had to manually downgrade wpa_supplicant to wpa_supplicant-2.6-17.fc29.x86_64.rpm . My network controller: Broadcom Inc. and subsidiaries BCM4352 802.11ac Wireless Network Adapter (rev 03) (as of lspci).
Hi, still present in wpa_supplicant 2.8 with kernel 5.1.7
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
> Feb 15 15:17:35 BRSINC-01Fed wpa_supplicant[950]: nl80211: Scan trigger failed: ret=-22 (Invalid argument) ... > bcm4360 and the broadcom-wl-6.30.223.271-9.fc30. This is a crap driver. We don't ship it in Fedora.
Hi Lubomir, I do know that it is a proprietary driver, which has not been updated for a long time, that there is no open-source alternative (to the best of my knowledge) and -- trust me -- I must keep working with my laptop for some time, hopefully with Fedora... If useful to the other users, I am using -- as a workaround -- what is provided here https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/ , which is simply a version of wpa_supplicant that does not use the features that "confuse" the driver, that substitutes the one shipped with Fedora. Then, is there no intent from RedHat/Fedora to incorporate the workaround into the main distribution? I am not saying to use the less powerful version of wpa_supplicant, but to make wpa_supplicant able to behave differently depending on the driver. Best wishes, Pierpaolo.
(In reply to pierpaolo.vittorini from comment #16) > Hi Lubomir, > > I do know that it is a proprietary driver, which has not been updated for a > long time, that there is no open-source alternative (to the best of my > knowledge) and -- trust me -- I must keep working with my laptop for some > time, hopefully with Fedora... > > If useful to the other users, I am using -- as a workaround -- what is > provided here > https://copr.fedorainfracloud.org/coprs/dcaratti/wpa_supplicant/ , which is > simply a version of wpa_supplicant that does not use the features that > "confuse" the driver, that substitutes the one shipped with Fedora. > > Then, is there no intent from RedHat/Fedora to incorporate the workaround > into the main distribution? I am not saying to use the less powerful version > of wpa_supplicant, but to make wpa_supplicant able to behave differently > depending on the driver. Pierpaolo, that's absolutely not what I meant to imply. The out-of-tree drivers generally require disproportionate amount of effort (that is: they're a major pain in the ass) and we do have finite resources that we'd prefer to spend on more meaningful things. Our usual tools and processes that we employ to develop and quality control things don't work for them. This is very irresponsible on the part of whoever shipped the broken driver to you. I do understand that you want your hardware to get, but I wish you've checked what the Linux support with whoever you got the hardware from. Please do not buy from vendors that don't care to spend a minimal amount of effort to have the hardware work with Linux! I'd be still happy to apply a patch to NetworkManager if it is reasonable. If it is against wpa_supplicant, then the wpa_supplicant upstream would have to accept it. I have no idea what the patch would be unless someone is going to send it to us; I don't plan on wasting my time on that. But ideally, you should just report the issue to whoever you got the broken driver from and have them fix it. We can't do that hence CLOSED/CANTFIX.
(In reply to Lubomir Rintel from comment #17) > want your hardware to get "want your hardware to work" sorry