Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1571256 - Can't connect to wpa_supplicant AP from newer Android
Summary: Can't connect to wpa_supplicant AP from newer Android
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: wpa_supplicant
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-24 12:12 UTC by Michal Růžička
Modified: 2018-11-30 21:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-30 21:28:16 UTC
Type: Bug


Attachments (Terms of Use)
Patch providing a best effort solution (2.96 KB, patch)
2018-04-24 12:12 UTC, Michal Růžička
no flags Details | Diff

Description Michal Růžička 2018-04-24 12:12:11 UTC
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

Comment 1 Michal Růžička 2018-05-03 15:23:21 UTC
The problem still exists in Fedora 28.

Comment 2 Beniamino Galvani 2018-05-03 15:57:53 UTC
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

Comment 3 Michal Růžička 2018-05-04 11:59:15 UTC
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.

Comment 4 Ben Cotton 2018-11-27 15:49:19 UTC
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.

Comment 5 Ben Cotton 2018-11-30 21:28:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.