Bug 1374756 - race in supplicant to detect MAC address change leads to failure to associate
Summary: race in supplicant to detect MAC address change leads to failure to associate
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: wpa_supplicant
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Thomas Haller
QA Contact: Ken Benoit
Depends On: 1371623 1374023
Blocks: 1313485 1446211
TreeView+ depends on / blocked
Reported: 2016-09-09 14:14 UTC by Thomas Haller
Modified: 2017-08-01 20:58 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of: 1374023
Last Closed: 2017-08-01 20:58:59 UTC

Attachments (Terms of Use)
[patch] [dist-git] [rhel-7.3] (5.30 KB, patch)
2016-09-16 11:55 UTC, Thomas Haller
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2053 normal SHIPPED_LIVE wpa_supplicant bug fix and enhancement update 2017-08-01 18:35:57 UTC

Description Thomas Haller 2016-09-09 14:14:11 UTC
+++ This bug was initially created as a clone of Bug #1374023 +++

for some drivers (brcmfmac), changing the MAC address doesn't take effect immediately.

There is a race where changing the MAC address of a device can be missed by wpa_supplicant. As a result, the later association fails.

See https://bugzilla.redhat.com/show_bug.cgi?id=1374023#c25 for details and logfile. See also upstream NetworkManager bug https://bugzilla.gnome.org/show_bug.cgi?id=770504#c12

With 1.4.0, NetworkManager would like to enable MAC address randomization by default. Thus the problem happens much more frequently.

Comment 4 Thomas Haller 2016-09-13 08:51:14 UTC
NetworkManager now works around this issue. So, it's of lower priority.

See https://bugzilla.redhat.com/show_bug.cgi?id=1374023#c30

Comment 5 Thomas Haller 2016-09-13 11:24:55 UTC
As kernel only allows to change the MAC address when the device is !IFF_UP, one might reasonably require that reading the MAC address when a device is IFF_UP is sufficient and the one might assume that the MAC address does not change afterwards. So, that part seems like a driver issue, and wpa_supplicant might just require a fixed driver.

On the other hand, it seems that wpa_supplicant could experience a race, where it would miss the fact that the MAC address went shortly down, and thus missing to re-read the MAC address...

Comment 7 Thomas Haller 2016-09-16 11:55:35 UTC
Created attachment 1201607 [details]
[patch] [dist-git] [rhel-7.3]

I summarized the issue here:
The issue is primarily with 2.1 release.

rhel-7.3's 2.0 does better. The reason why the issue doesn't usually happen is due to wpa_supplicant_update_mac_addr(), which hits:

»···} else if (!(wpa_s->drv_flags &
»···»···wpa_s->l2 = l2_packet_init(wpa_s->ifname,

to reload the MAC address and finally setting wpa_sm_set_own_addr().

I think the attached patch is still the correct thing to do, but it's unclear when the situation is actually necessary.

Comment 9 Thomas Haller 2017-03-08 10:34:39 UTC
with upcoming 2.6 rebase, this will be fixed automatically.

Comment 11 Ken Benoit 2017-05-31 18:14:53 UTC
Tested against RHEL-7.4-20170525.7 and was unable to reproduce the failure to associate to an AP when the MAC address changes. Marking as verified.

Comment 12 errata-xmlrpc 2017-08-01 20:58:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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