Description of problem: I recently installed Fedora 28 atomic workstation on my E7440. Everything works before I updated away from 28.1.1... I was unable to update via gnome-software, so I used `rpm-ostree upgrade`, which worked, but post upgrade, my 7260 repeatedly connects and disconnects from the network at work, making it impossible to use. Version-Release number of selected component (if applicable): NAME=Fedora VERSION="28 (Workstation Edition)" ID=fedora VERSION_ID=28 PLATFORM_ID="platform:f28" PRETTY_NAME="Fedora 28 (Workstation Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:28" HOME_URL="https://fedoraproject.org/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=28 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=28 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation How reproducible: 100% Steps to Reproduce: 1.Install Fedora 28 on a laptop with a Intel 7260 wireless adapter 2.Update to the next kernel version 3. Actual results: Being that it works on 28.1.1 I'd hope that it would work on the next version (I don't remember what that number was). Expected results: After upgrading away from 28.1.1 the 7260 in my E7440 is broken Additional info: I have a feeling I'm not the only person that is seeing this issue...
Here are some dmesg logs if they are helpful: [ 327.799557] wlp2s0: deauthenticating from 28:34:a2:81:cb:c0 by local choice (Reason: 1=UNSPECIFIED) [ 327.983512] wlp2s0: authenticate with 0c:11:67:35:98:a0 [ 327.987191] wlp2s0: send auth to 0c:11:67:35:98:a0 (try 1/3) [ 327.990869] wlp2s0: authenticated [ 327.991964] wlp2s0: associate with 0c:11:67:35:98:a0 (try 1/3) [ 327.994112] wlp2s0: RX AssocResp from 0c:11:67:35:98:a0 (capab=0x111 status=0 aid=2) [ 327.995467] wlp2s0: associated [ 328.003597] wlp2s0: deauthenticating from 0c:11:67:35:98:a0 by local choice (Reason: 1=UNSPECIFIED) [ 328.182237] wlp2s0: authenticate with 28:34:a2:81:cb:c0 [ 328.185314] wlp2s0: send auth to 28:34:a2:81:cb:c0 (try 1/3) [ 328.187105] wlp2s0: authenticated [ 328.188258] wlp2s0: associate with 28:34:a2:81:cb:c0 (try 1/3) [ 328.191934] wlp2s0: RX AssocResp from 28:34:a2:81:cb:c0 (capab=0x111 status=0 aid=6)
More info... 1528478775.728892: nl80211: set_key failed; err=-22 Invalid argument) the very next line is... 1528478775.728895: wlan0: WPA: Failed to configure IGTK to the driver
(In reply to izzy from comment #2) > More info... > > 1528478775.728892: nl80211: set_key failed; err=-22 Invalid argument) > > the very next line is... > > 1528478775.728895: wlan0: WPA: Failed to configure IGTK to the driver hello, the above error looks like a message from wpa_supplicant, getting -EINVAL after associating to an Access Point where Protected Management Frames (IEEE802.11w) are available. Can you please provide the following information? 1) check if iwlwifi has any option in /etc/modprobe.d/, as follows: $ grep iwlwifi /etc/modprobe.d/* 2) provide the output of iw phy0 info, as follows: $ iw phy0 info thanks! -- davide
Whoops, sorry I didn't get back to you sooner. [izzy@ip-10-0-65-109 izzy]$ grep iwlwifi /etc/modprobe.d/* (there was no output from this grep) [izzy@ip-10-0-65-109 izzy]$ iw phy0 info Wiphy phy0 max # scan SSIDs: 20 max scan IEs length: 425 bytes max # sched scan SSIDs: 20 max # match sets: 11 max # scan plans: 2 max scan plan interval: 65535 max scan plan iterations: 254 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Device supports AP-side u-APSD. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP-128 (00-0f-ac:4) * CMAC (00-0f-ac:6) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * P2P-client * P2P-GO * P2P-device Band 1: Capabilities: 0x11ee HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT Max RX data rate: 300 Mbps HT TX/RX MCS rate indexes supported: 0-15 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (22.0 dBm) * 2417 MHz [2] (22.0 dBm) * 2422 MHz [3] (22.0 dBm) * 2427 MHz [4] (22.0 dBm) * 2432 MHz [5] (22.0 dBm) * 2437 MHz [6] (22.0 dBm) * 2442 MHz [7] (22.0 dBm) * 2447 MHz [8] (22.0 dBm) * 2452 MHz [9] (22.0 dBm) * 2457 MHz [10] (22.0 dBm) * 2462 MHz [11] (22.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) Band 2: Capabilities: 0x11ee HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 4 usec (0x05) HT Max RX data rate: 300 Mbps HT TX/RX MCS rate indexes supported: 0-15 VHT Capabilities (0x038071a0): Max MPDU length: 3895 Supported Channel Width: neither 160 nor 80+80 short GI (80 MHz) TX STBC SU Beamformee VHT RX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: not supported 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT RX highest supported: 0 Mbps VHT TX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: not supported 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT TX highest supported: 0 Mbps Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 5180 MHz [36] (22.0 dBm) (no IR) * 5200 MHz [40] (22.0 dBm) (no IR) * 5220 MHz [44] (22.0 dBm) (no IR) * 5240 MHz [48] (22.0 dBm) (no IR) * 5260 MHz [52] (22.0 dBm) (no IR, radar detection) * 5280 MHz [56] (22.0 dBm) (no IR, radar detection) * 5300 MHz [60] (22.0 dBm) (no IR, radar detection) * 5320 MHz [64] (22.0 dBm) (no IR, radar detection) * 5500 MHz [100] (22.0 dBm) (no IR, radar detection) * 5520 MHz [104] (22.0 dBm) (no IR, radar detection) * 5540 MHz [108] (22.0 dBm) (no IR, radar detection) * 5560 MHz [112] (22.0 dBm) (no IR, radar detection) * 5580 MHz [116] (22.0 dBm) (no IR, radar detection) * 5600 MHz [120] (22.0 dBm) (no IR, radar detection) * 5620 MHz [124] (22.0 dBm) (no IR, radar detection) * 5640 MHz [128] (22.0 dBm) (no IR, radar detection) * 5660 MHz [132] (22.0 dBm) (no IR, radar detection) * 5680 MHz [136] (22.0 dBm) (no IR, radar detection) * 5700 MHz [140] (22.0 dBm) (no IR, radar detection) * 5720 MHz [144] (22.0 dBm) (no IR, radar detection) * 5745 MHz [149] (22.0 dBm) (no IR) * 5765 MHz [153] (22.0 dBm) (no IR) * 5785 MHz [157] (22.0 dBm) (no IR) * 5805 MHz [161] (22.0 dBm) (no IR) * 5825 MHz [165] (22.0 dBm) (no IR) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * new_mpath * set_mesh_config * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * remain_on_channel * set_tx_bitrate_mask * frame * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * start_sched_scan * probe_client * set_noack_map * register_beacons * start_p2p_device * set_mcast_rate * connect * disconnect * channel_switch * set_qos_map * add_tx_ts * set_multicast_to_unicast Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0x40 0xb0 0xc0 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * mesh point: 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-device: 0x40 0xd0 WoWLAN support: * wake up on disconnect * wake up on magic packet * wake up on pattern match, up to 20 patterns of 16-128 bytes, maximum packet offset 0 bytes * can do GTK rekeying * wake up on GTK rekey failure * wake up on EAP identity request * wake up on 4-way handshake * wake up on rfkill release * wake up on network detection, up to 11 match sets software interface modes (can always be added): * AP/VLAN * monitor valid interface combinations: * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1, total <= 3, #channels <= 2 HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS. Device supports SAE with AUTHENTICATE command Device supports low priority scan. Device supports scan flush. Device supports per-vif TX power setting P2P GO supports CT window setting P2P GO supports opportunistic powersave setting Driver supports full state transitions for AP/GO clients Driver supports a userspace MPM Driver/device bandwidth changes during BSS lifetime (AP/GO mode) Device supports static SMPS Device supports dynamic SMPS Device supports WMM-AC admission (TSPECs) Device supports configuring vdev MAC-addr on create. [izzy@ip-10-0-65-109 izzy]$
can you please try disabling the PMF? $ nmcli connection modify wifi-sec.pmf disable; nmcli connection up (and in case disabling PMF results in a successful connection, can you please attach a trace with EAPOL packets, as follows? # tcpdump -s 0 -i any ether proto 0x888e -w eapol.pcap & $ nmcli connection modify wifi-sec.pmf disable; nmcli connection up thanks! -- davide
(In reply to Davide Caratti from comment #5) > can you please try disabling the PMF? > # tcpdump -s 0 -i any ether proto 0x888e -w eapol.pcap & > $ nmcli connection modify wifi-sec.pmf disable; nmcli connection up (sorry, I forgot to put the needinfo and also made a mistake in comment #5) can you please try disabling the PMF? $ nmcli connection modify wifi-sec.pmf disable; nmcli connection up (and in case disabling PMF results in a successful connection), can you please attach a trace with EAPOL packets, as follows? # tcpdump -s 0 -i any ether proto 0x888e -w eapol.pcap & $ nmcli connection modify wifi-sec.pmf optional; nmcli connection up (wait for connection failure, then:) $ nmcli connection modify wifi-sec.pmf disable; nmcli connection up thanks! -- davide
[izzy@ip-10-0-64-110 izzy]$ nmcli connection modify wifi-sec.pmf disable; nmcli connection up Error: unknown connection 'wifi-sec.pmf'. Error: neither a valid connection nor device given. hmm I did capture the trace though, I attached it to the ticket
Created attachment 1475957 [details] eapol trace
(In reply to izzy from comment #7) > [izzy@ip-10-0-64-110 izzy]$ nmcli connection modify wifi-sec.pmf disable; > nmcli connection up > Error: unknown connection 'wifi-sec.pmf'. > Error: neither a valid connection nor device given. my fault, I mistakenly omitted the connection name. The correct command to disable PMF (and see if the connection recovers) is: $ nmcli connection modify $CON_NAME wifi-sec.pmf disable; nmcli connection up $CON_NAME where $CON_NAME is the name of your wifi connection, and can be obtained with: $ nmcli connection show > > hmm > > I did capture the trace though, I attached it to the ticket thanks. In EAPOL 2/4 the client advertises the BIP cipher suite (00-0f-ac:6), which does not seem incorrect. It would be nice to understand what IGTK is failing the installation to do so, can you enable verbose wpa_supplicant debug, i.e. : 1. modify /etc/sysconfig/wpa_supplicant to enable verbose log, and restart wpa_supplicant OTHER_ARGS="-s -dd" # systemctl restart wpa_supplicant.service 2. enable pmf again $ nmcli connection modify $CON_NAME wifi-sec.pmf optional; nmcli connection up $CON_NAME 3. provide the debug log journalctl -u wpa_supplicant -n5000 (so that we search for lines starting with 'wpa_driver_nl80211_set_key': with alg=....). can you please help? thank you in advance! -- davide
In the process of running your instructions my WiFi began to work again, it's currently working now. I'll attach the log nonetheless.
Created attachment 1477330 [details] debug requested
(In reply to izzy from comment #11) > Created attachment 1477330 [details] > debug requested thank you. I assume you WiFi restored its functionality after you disabled PMF, correct? In the log you attached I see: wpa_supplicant[8042]: wlan0: WPA: Selected mgmt group cipher 32 ... and then wpa_supplicant[8042]: wlan0: WPA: not using MGMT group cipher but since #define WPA_CIPHER_AES_128_CMAC BIT(5) in src/common/defs.h, your AP is requesting you CMAC and your driver apparently is supporting it (as per comment #4). Just to be sure, can you temporarily enable PMF again, nmcli connection modify $CON_NAME wifi-sec.pmf optional; nmcli connection up $CON_NAME and re-attach the verbose log? thanks for cooperating! -- davide
Created attachment 1477655 [details] wifi log with pmf enabled again
Yes, with PMF disabled the WiFi at the office was working fine. Not sure if that is a good permanent fix though. There were just updates to the firmware drivers for the 7260 I saw in the App Center, they didn't seem to help though.
(In reply to izzy from comment #14) > Yes, with PMF disabled the WiFi at the office was working fine. Not sure if > that is a good permanent fix though. There were just updates to the firmware > drivers for the 7260 I saw in the App Center, they didn't seem to help > though. thanks for the update. Looking at the log, I noticed the relevan lines: Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: wlan0: WPA: IGTK keyid 1024 pn 000000000000 Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: WPA: IGTK - hexdump(len=16): [REMOVED] Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=4 addr=0x558dcbf04434 key_idx=1024 set_tx=0 seq_len=6 key_le> Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: nl80211: KEY_DATA - hexdump(len=16): [REMOVED] Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: nl80211: KEY_SEQ - hexdump(len=6): 00 00 00 00 00 00 Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: broadcast key Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: nl80211: set_key failed; err=-22 Invalid argument) Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: wlan0: WPA: Failed to configure IGTK to the driver Aug 21 10:25:23 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: wlan0: RSN: Failed to configure IGTK The access point in my home (hostapd running on mips32 big endian) is sending the IGTK with key_idx equal to 4. The access point in your office is sending the IGTK with key_idx equal to 1024. And probably the Linux kernel rejects this, because of [1]. Wild guess: since 1024 is equal to htons(4), and the keyid is stored in a 16bit field, and other keys (like the broadcast and the unicast keys) have valid indexes, could this behavior be ascribed as an endianess bug in the Access Point? any opinion appreciated! -- davide [1] https://elixir.bootlin.com/linux/v4.18.4/source/net/wireless/nl80211.c#L936
(In reply to Davide Caratti from comment #15) > (In reply to izzy from comment #14) > > The access point in my home (hostapd running on mips32 big endian) is > sending the IGTK with key_idx equal to 4. The access point in your office is > sending the IGTK with key_idx equal to 1024. > > And probably the Linux kernel rejects this, because of [1]. Wild guess: > since 1024 is equal to htons(4), and the keyid is stored in a 16bit field, > and other keys (like the broadcast and the unicast keys) have valid indexes, > could this behavior be ascribed as an endianess bug in the Access Point? > > any opinion appreciated! > -- > davide > > [1] > https://elixir.bootlin.com/linux/v4.18.4/source/net/wireless/nl80211.c#L936 after looking again at the log, Aug 21 10:25:24 ip-10-0-64-110.endlessm-sf.com wpa_supplicant[19361]: wlan0: WPA: IGTK keyid 1024 pn 000000000000 this looks similar to the log of https://bugzilla.redhat.com/show_bug.cgi?id=1595319 . Here the key index was 1280, which equals to htons(5). According to IEEE802.11 standard (§8.4.2.57), the only valid values for the Key ID of IGTK are 4 and 5, and all other values are reserved: because of this, the suspect of an endianess bug in the Access Point is more than a "wild guess" :) I'm closing this as DUPLICATE. Also in this case, an upgrade of the Access Point should fix the reported issue. In the meanwhile, you can keep PMF disabled for that connection. thank you very much for helping! regards, -- davide *** This bug has been marked as a duplicate of bug 1595319 ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days