Issue with some devices not connecting to Raspberry Pi set up as AP

Question

I have set up my Raspberry Pi (Raspberry Pi 4) as an Access Point by following this article: Setting up a Raspberry Pi as an access point - the easy way and section: Setting up an access point with a bridge.

I change the config to use WPA2 Personal (only) and tested and it works but only for some devices which is strange. For the moment 2 out of 4 devices seem to be able to connect while the others are not able.

Working devices:

• iPad Pro (latest release)
• Macbook Pro (latest OSX release)

Not working:

• iPhone (latest iOS release)
• PC with Windows 10 Pro

When changing from WPA2 to WPA1 my iPhone is able to connect but gives a security warning/information. Nevertheless using WPA1 cannot be the solution ;)

Checking the logs (syslog) I can see the device is connecting/disconnecting but no error.

my wpa_supplicant config

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=GB

network={
        ssid="AP SSID"
        psk="my pass"
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        auth_alg=OPEN
        mode=2
        frequency=2462
}

Any suggestion or help is appreciated on this matter.

Answer 1

I can confirm that MS Windows 10 has a problem to connect to an access point established by wpa_supplicant (using mode=2) and only accepting WPA2 (RSN) encryption. I haven't seen this before in my tutorial you have used, because I still use WPA encryption as fallback. And that works.

About IPhone I cannot say something because I don't have one.

I have looked at the debug output of wpa_supplicant and see that MS Windows 10 just does not response to the WPA 4-Way Handshake initiated by wpa_supplicant. Because MS Windows 10 can connect to my home WiFi internet hotspot using WPA2, I suspect that wpa_supplicant has a problem here. You may consider to file a bug report to the wpa_supplicant development.

You can also try to use hostapd instead of wpa_supplicant.

Answer 2

This appears to be a broader insidious issue with wpa_supplicant (on Debian only?), and not limited to the Pi. After many, many hours of following misleading symptoms, I can confirm that with:

• wpa_supplicant 2.8 on Debian Buster with default config plus mode=2, ssid and psk set, and every permutation of pairwise, group, auth_alg, frequency that could reasonable be tested;
• a wl81xxMOD WiFi module and the mainline wl81xx/wlcore kernel drivers;
• dnsmasq providing DHCP.

The client experience is either:

• connect without issue:
  • Early 2013 MacBook Pro running macos 10.14.6 (Mojave)
  • iPhone SE running iOS 13.6
  • Old Toshiba laptop running Windows 7
• report "unable to connect" or periodically cycle from connected to disconnected every 2 to 6 seconds:
  • Late model desktop PC running Windows 10.
  • Ancient ASUS laptop running Windows 10.
  • 2020 iMac running macos 10.15.6 (Catalina)

Changing to either Open (key_mgmt=NONE) or disabling WPA2 (proto=wpa) causes all clients to connect without issue.

My theory, uncomfortable as it is, is:

wpa_supplicant, by default, advertises WPA and WPA2 but does not provide a WPA2 Authenticator. Old clients just use WPA and never notice. Newer clients (including Mojave on a 2020 iMac) try WPA2, which does not complete so they drop the connection and mystery abounds.

The resolution appears to be:

wpa_supplicant must be configured with proto=wpa to disable WPA2, or wpa_supplicant must be replaced with something that provides an WPA2 Authenticator like hostapd.

This is despite the wpa_supplicant Change Log stating that way back in 2009-11-21 (v0.7.0), parts of hostapd functionality were linked in so that "AP mode functionality can be used for WPA2-Personal networks". On the other hand, the author's web page does state that wpa_supplicant implements "a WPA Authenticator" while hostapd includes a "IEEE 802.1X/WPA/WPA2 Authenticator".

I still do not understand why for those clients that take 6 seconds before disassociation, the WiFi connection appears to be completely useable. If it really is an authentication issue, that seems like a glaring security hole.

Full log of my investigation that led to this conclusion appears here.