Description of problem: When trying to connect to a WPA2 secured access point (SSID altitude), it fails to connect. Either nothing happens (no error in the GUI at all, just three dots for the wifi icon in the menu bar) or I get an additional modal dialog prompt to reinput the passphrase. Problem does not happen when connecting to the same AP (different SSID that is not WPA2 secured). Problem does not happen to this same AP from any other device including Fedora 27. Problem does not happen with the hardware used in this bug with Fedora 26. So the problem is something a.) about this hardware and b.) a regression in some component of Fedora 27 related to WPA2 authentication. Version-Release number of selected component (if applicable): kernel 4.13.13-300.fc27.x86_64 wpa_supplicant-2.6.12.fc27.x86_64 NetworkManager-1.8.4-7.fc.x86_64 How reproducible: Always Steps to Reproduce: 1. Menu bar > select network > choose altitude > input passphrase 2. 3. Actual results: a.) nothing, no error message at all, just three dots as the wifi icon in menu bar b.) every 30 seconds or so a dialog appears reasking for the wifi passphrase Expected results: Should connect. Worked with Fedora 26. Additional info:
Created attachment 1356953 [details] journal journalctl -b -o short-monotonic, wpa_supplicant running with -d option The connection is initiated at about 55 monotonic time (before that I think you can see wired ethernet being unplugged). I can't tell if this is kernel related, NetworkManager related, or wpa_supplicant related. But the fact it does connect without WPA2 suggests it's a wpa_supplication problem; whereas the fact other hardware has no problem suggests it's a kernel problem. *shrug* Suspicious lines: [ 58.497218] f27m.localdomain kernel: wlp3s0b1: f8:a0:97:6e:c7:e7 denied association (code=1) [ 59.538346] f27m.localdomain wpa_supplicant[1002]: wlp3s0b1: CTRL-EVENT-ASSOC-REJECT bssid=f8:a0:97:6e:c7:e7 status_code=1 [ 59.538691] f27m.localdomain wpa_supplicant[1002]: wlp3s0b1: SME: Deauth request to the driver failed Attempts by NM to connect continue through 161 monotonic time, where I give up.
Created attachment 1356965 [details] lspci -vvnn 03:00.0 Network controller [0280]: Broadcom Limited BCM4331 802.11a/b/g/n [14e4:4331] (rev 02) I am using the kernel b43 driver for this, with what seems like ancient firmware. [ 160.935298] f27m.localdomain kernel: b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
Created attachment 1356966 [details] lsmod
OK interesting, there is much newer firmware. I've found broadcom-wl-6.30.163.46.wl_apsta.o at https://aur.archlinux.org/packages/b43-firmware/ and installed that with b43-fwcutter which gets me: [ 6.911185] f27m.localdomain kernel: b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19) But it still fails to connect.
Created attachment 1356968 [details] journal2 Obsoleting the first journal because wpa_supplicant -d option was wiped out by dnf update which included wpa_supplicant stepping on the service file. And also to account for the latest available version of b43 firmware. This contains a lot more wpa_supplicant info.
[ 64.420156] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: BSS: Start scan result update 5 But what follows are many SSID '' results, instead of including the SSID. And among them missing is 'altitude' which is only 5 feet away, and every other device around here can see that SSID fine. And then we end up with: [ 64.441716] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: No suitable network found ====== But we get an interesting followup attempt starting at monotonic time 69.426254. [ 70.287672] f27m.localdomain wpa_supplicant[995]: EAPOL: External notification - EAP success=0 [ 70.287902] f27m.localdomain wpa_supplicant[995]: EAPOL: External notification - EAP fail=0 [ 70.288133] f27m.localdomain wpa_supplicant[995]: EAPOL: External notification - portControl=Auto [ 70.288369] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: Determining shared radio frequencies (max len 1) [ 70.288601] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: Shared frequencies (len=0): completed iteration [ 70.288828] f27m.localdomain wpa_supplicant[995]: nl80211: Authenticate (ifindex=3) [ 70.289147] f27m.localdomain kernel: wlp3s0b1: RX AssocResp from f8:a0:97:6e:c7:e7 (capab=0x1431 status=1 aid=0) [ 70.289148] f27m.localdomain kernel: wlp3s0b1: f8:a0:97:6e:c7:e7 denied association (code=1) [ 70.289192] f27m.localdomain wpa_supplicant[995]: * bssid=f8:a0:97:6e:c7:e7 [ 70.289442] f27m.localdomain wpa_supplicant[995]: * freq=2412 [ 70.289676] f27m.localdomain wpa_supplicant[995]: * IEs - hexdump(len=0): [NULL] [ 70.289910] f27m.localdomain wpa_supplicant[995]: * Auth Type 0 [ 70.290188] f27m.localdomain wpa_supplicant[995]: nl80211: Authentication request send successfully Right in the middle of wpa_supplicant authentication, the kernel denies association - if the times are trustworthy. [ 70.319536] f27m.localdomain wpa_supplicant[995]: nl80211: Associate event [ 70.319777] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: Event ASSOC_REJECT (13) received [ 70.319966] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: CTRL-EVENT-ASSOC-REJECT bssid=f8:a0:97:6e:c7:e7 status_code=1 [ 70.320244] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: SME: Association with f8:a0:97:6e:c7:e7 failed: status code 1 [ 70.320507] f27m.localdomain wpa_supplicant[995]: wpa_driver_nl80211_deauthenticate(addr=f8:a0:97:6e:c7:e7 reason_code=3) [ 70.320764] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: nl80211: MLME command failed: reason=3 ret=-107 (Transport endpoint is not connected) [ 70.321019] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: SME: Deauth request to the driver failed [ 70.321280] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: Radio work 'sme-connect'@0x55a5c002a9b0 done in 0.056005 seconds [ 70.321546] f27m.localdomain wpa_supplicant[995]: wlp3s0b1: radio_work_free('sme-connect'@0x55a5c002a9b0: num_active_works --> 0 [ 70.321809] f27m.localdomain wpa_supplicant[995]: Added BSSID f8:a0:97:6e:c7:e7 into blacklist And then this BSSID ends up in a blacklist (?). It sounds to me like both kernel and wpa_supplicant are confusing each other... but I really have the most rudimentary understanding.
Downgrade to kernel 4.11.9 does not fix the problem. Downgrade to wpa_supplicant-2.6-6.fc27.x86_64 does not fix the problem. And downgrading to Fedora 26 clean (not updated) does not fix the problem. OOOKAY...
OK so I've downgraded to Fedora 25, does not work. And Fedora 24, does not work. All the same failure vector. It looks like linux + this client radio + this AP are not compatible and maybe never were (the AP is Xfinity branded and it was replaced in the previous 12 months.) Curiously, this does work if I change any of those three things, including merely rebooting and using macOS. That connects but linux does not, so there is a bug here, but it's probably in the kernel's b43 driver. I'll take this upstream.
Created attachment 1357002 [details] 80211 kernel configs grep 80211 /boot/config-4.13.13-300.fc27.x86_64
Created attachment 1357017 [details] journal3 This is back to Fedora 27, kernel 4.13.13, and while monitoring with iw I see a successful connection, briefly before it fails. The successful connection starts at monotonic time 304 in this log. Subsequent reconnects fail. I do not know why there's a one time success here, maybe there's a race happening between kernel driver and wpa_supplicant.
Created attachment 1357018 [details] iw -t This iw -t goes with 'journal3' log previously attached.
systemd's wpa_supplicant.service uses this: /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -s
Access point is an Xfinity branded Arris TG1682G, 802.11a/b/g/n/ac eMTA & DOCSIS Software Version: 10.1.11.SIP.PC20.CT Software Image Name: TG1682_2.8p7s1_PROD_sey
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.