diff options
| author | Amarnath Hullur Subramanyam <amarnath@codeaurora.org> | 2015-09-18 06:57:06 -0700 |
|---|---|---|
| committer | The Android Automerger <android-build@google.com> | 2015-09-18 18:06:24 -0700 |
| commit | e97a2cebd268207a9918c3bbdc8660de51544ffd (patch) | |
| tree | 7ad78c9bc4cfb3b74ff48f30b11cb6a0d8627530 /src/common | |
| parent | bcb09cb61718a5dc16cbbdba5c670eeee7c167c4 (diff) | |
| download | android_external_wpa_supplicant_8-e97a2cebd268207a9918c3bbdc8660de51544ffd.tar.gz android_external_wpa_supplicant_8-e97a2cebd268207a9918c3bbdc8660de51544ffd.tar.bz2 android_external_wpa_supplicant_8-e97a2cebd268207a9918c3bbdc8660de51544ffd.zip | |
Update AP WPA/RSN IE on all associations if driver can select BSS
It is possible for driver-based BSS selection to end up reassociating
back to the current AP. If wpa_supplicant preferred another BSS, it
would have updated the internal knowledge of the AP's WPA/RSN IE when
requesting a new connection. In the special case of existing association
and new association being with the same BSS that is different from the
wpa_supplicant preference, association event processing skipped the
WPA/RSN IE update. This could result in the following 4-way handshake
getting rejected due to incorrectly detected mismatch with AP's RSN/WPA
IE between Beacon/Probe Response frame and EAPOL-Key msg 3/4.
Fix this by updating the AP WPA/RSN IE on all association events when
driver-based BSS selection is used regardless of whether the BSSID
changes. This could also cover a theoretical case of the AP changing its
RSN/WPA IE at the very moment we try to reassociate back to the same
BSS.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Change-Id: If37977900badf39603fad6c8ffadfe7d16e826ae
Bug: 24110113
Diffstat (limited to 'src/common')
0 files changed, 0 insertions, 0 deletions