Bug 1374756

Summary: race in supplicant to detect MAC address change leads to failure to associate
Product: Red Hat Enterprise Linux 7 Reporter: Thomas Haller <thaller>
Component: wpa_supplicantAssignee: Thomas Haller <thaller>
Status: CLOSED ERRATA QA Contact: Ken Benoit <kbenoit>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: atragler, bgalvani, dcaratti, dcbw, desktop-qa-list, hartsjc, lrintel, rkhan, thaller
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: 1374023 Environment:
Last Closed: 2017-08-01 20:58:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1371623, 1374023    
Bug Blocks: 1313485, 1446211    
Attachments:
Description Flags
[patch] [dist-git] [rhel-7.3] none

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 6 Thomas Haller 2016-09-14 16:27:26 UTC 
see also https://bugzilla.gnome.org/show_bug.cgi?id=771005#c21 and https://bugzilla.gnome.org/show_bug.cgi?id=771005#c22.
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:
https://bugzilla.gnome.org/show_bug.cgi?id=771005#c37
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_DRIVER_FLAGS_P2P_DEDICATED_INTERFACE)) {
»···»···l2_packet_deinit(wpa_s->l2);
»···»···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.

https://access.redhat.com/errata/RHBA-2017:2053