Hello, We have an i.MX6 embedded platform using a soldered down Silex SX- SDMAC-2832S; a QCA9377 chipset supported by ath10k_sdio with firmware in linux-firmware since somewhere around kernel 5.10. In the 4.9 LTS we used a proprietary driver and firmware provided by Silex. Since kernel 5.10, through the latest 6.12 we've been facing an issue where this device no longer connects to a WPA2-PSK when using wpa_supplicant 2.10 or newer (other encryption methods untested, open networks connect fine). Downgrading to wpa_supplicant 2.9 works without issue and we've been using that as a workaround hoping newer kernel or hostap releases would resolve the issue. Now that we're working in 6.6 and 6.12, the issue is still present unfortunately: # wpa_supplicant -iwlan0 -c wpa.conf Successfully initialized wpa_supplicant wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: SME: Trying to authenticate with aa:bb:cc:dd:ee:ff (SSID='my_ssid' freq=5240 MHz) wlan0: Trying to associate with aa:bb:cc:dd:ee:ff (SSID='my_ssid' freq=5240 MHz) wlan0: Associated with 8aa:bb:cc:dd:ee:ff wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlan0: CTRL-EVENT-DISCONNECTED bssid=aa:bb:cc:dd:ee:ff reason=15 wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="my_ssid" auth_failures=1 duration=10 reason=WRONG_KEY BSSID aa:bb:cc:dd:ee:ff ignore list count incremented to 2, ignoring for 10 seconds wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="my_ssid" However, simply switching to wpa_supplicant 2.9: # wpa_supplicant -iwlan0 -c wpa.conf Successfully initialized wpa_supplicant wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN wlan0: SME: Trying to authenticate with aa:bb:cc:dd:ee:ff (SSID='my_ssid' freq=5240 MHz) wlan0: Trying to associate with aa:bb:cc:dd:ee:ff (SSID='my_ssid' freq=5240 MHz) wlan0: Associated with aa:bb:cc:dd:ee:ff wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlan0: WPA: Key negotiation completed with aa:bb:cc:dd:ee:ff [PTK=CCMP GTK=CCMP] wlan0: CTRL-EVENT-CONNECTED - Connection to aa:bb:cc:dd:ee:ff completed [id=0 id_str=] I was able to bisect through hostap and found this commit as the first breaking commit: https://w1.fi/cgit/hostap/commit/?id=144314eaa7e09374b7f9a3708263a298e05cbfd6 Reverting that change on the hostap_2_10 and hostap_2_11 tags allowed me to connect to the network again on those builds. Looking through hostap and kernel code, net/mac80211/main.c sets the ext_feature NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 which hostap reads and calls WPA_DRIVER_FLAGS_CONTROL_PORT. Unsetting that feature in net/mac80211/main.c completely breaks even associating with the AP. Unfortunately this is where my understanding of the Linux networking system ends and I'm unsure where to start looking now to get to the bottom of this. The ath10k driver obviously needs NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 enabled, but I'm unsure if the connection failures are a driver or firmware issue. At the very least I'm now certain it is not a hostap issue. I would appreciate any insight to the issue. Happy to do any further testing or provide additional output as needed. -Kris embeddedTS
