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

        ssid="AP SSID"
        psk="my pass"
        pairwise=CCMP TKIP

Any suggestion or help is appreciated on this matter.

  • I will have a look at it but I do not have an iPhone so I cannot test this. Is there a big difference between an iPad Pro and an iPhone? I will look for a MS Windows 10 computer for testing. Just a moment please, will come back then.
    – Ingo
    Commented May 12, 2020 at 19:18
  • I can confirm that Windows 10 does not connect with WPA2 only. I'm just looking at the debug output of wpa_supplicant.
    – Ingo
    Commented May 13, 2020 at 17:42

2 Answers 2


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.