Created attachment 1425981 [details] Patch providing a best effort solution Description of problem: It is not possible to connect from newer Android devices to a Soft AP controlled by wpa_supplicant. The problem is that the newer Android devices encrypt the 4th message of the WPA 4-way handshake which is not supported by wpa_supplicant. Version-Release number of selected component (if applicable): 2.6-13.fc27 How reproducible: Almost always (I've seen it connect only once or twice out of hundreds of attempts.) Steps to Reproduce: 1. configure a WiFi connection of type "Access Point" (802-11-wireless.mode: ap) in NetworkManager; configure the connection to use WPA/WPA2 security 2. activate the connection 3. try connecting to the created WiFi network from a newer Android device (Android 6 and above, I've experienced the problem with: Samsung Galaxy J7 2016 [Android 7.0], Samsung Galaxy S5 mini [Android 6.0], devices with older versions of Android don't have the problem: Samsung Galaxy S4 mini [Android 5.0], Samsung Galaxy S2 [Android 4.2] work fine) Actual results: The Android device fails to connect to the WiFi network. Expected results: The Android device connects to the WiFi network. Additional info: The problem is that the newer Android devices send the 4th message of the WPA 4-way handshake encrypted. (The device believes at that moment that the connection is established successfully.) But when such a message is received by the host running the wpa_supplicant Soft AP, it is likely dropped by the kernel because it cannot be decrypted so it doesn't even make it to the wpa_supplicant, or if it makes it, then it is ignored by the supplicant because it is not expected to be encrypted. In any case from the wpa_supplicant's point of view the 4-way handshake is not successfully completed, so after resending the message 3 of the handshake a couple of times, it disassociates the Android device. In the attached patch I'm dealing with the issue by installing the pairwise transient key - PTK (the key used by the Android device to encrypt the message 4) to the kernel as soon as the message 3 of the handshake is sent by the wpa_supplicant. The idea is to make sure the key is in the kernel at the time the encrypted message 4 is received so that it can be decrypted and forwarded to the wpa_supplicant which upon its receipt considers the 4-way handshake to be completed successfully. Note that the key cannot be installed before sending the message 3 as otherwise it would have been encrypted too and that would have been a real showstopper. Although the patch seems to solve the issue quite reliably I consider it to be only a temporary solution as it unfortunately includes a race: - if the PTK key is installed in the kernel before the message 4 is received, then when the message is received it is decrypted, forwarded to the wpa_supplicant and as a result the 4-way handshake succeeds - if OTOH the message is received before the PTK key is installed then it is ignored and the handshake fails The definitive solution should install the key before the message 3 is sent and then somehow send the message 3 unencrypted despite the key being installed in the kernel. As far as I can tell this is not possible in the current kernels, but it seems to be coming down the pipe: [1] [1] https://github.com/torvalds/linux/commit/2576a9ace47eba28a682d249d1d6402f891808c9#diff-6c2a071a3bad859b6dabb535217e11c4
The problem still exists in Fedora 28.
Hi, thanks for the patch! Any changes in the wpa_supplicant Fedora package should be first applied upstream, so you should send the patch to the hostap mailing list: https://lists.infradead.org/mailman/listinfo/hostap
Hi, I consider the patch a temporary solution (as it is racy and as a consequence can be totally ineffective on slower hardware) and as such not suitable for upstream. Upstream should IMO pursue the solution I outline in the description: installing the PTK key even before sending the message 3 of the 4-way handshake and despite that sending the message 3 unencrypted possibly by taking advantage of the recently added feature of nl80211 I refer to in the description - [1]. As a temporary solution it seems reasonable to me to apply the patch in the RPM and drop it once upstream implements the proper solution.
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.