On Wed, 2017-01-04 at 22:24 +0100, Rafał Miłecki wrote: > On 4 January 2017 at 17:25, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > > Well, I have updated NM to version 1.4.2 (previously version > > > 1.2.x > > > was > > > used) and the problem seems to be gone. It is not quite obvious > > > to > > > me > > > from NM's git repo yet, how exactly if was fixed but still. > > > > After the randomization was deployed, the NM team found some issues > > where NM didn't wait long enough (or verify well enough) that some > > drivers had actually changed the MAC address before continuing with > > configuration. That impacted drivers like wl, brcmfmac, and some > > others that report "success!" to the MAC change request, but don't > > actually change the MAC address for a short period of time. NM was > > not > > waiting for the change to actually happen in the device, and was > > assuming that the driver had changed the MAC after reporting > > success. > > Would you care to report this to wireless team (brcmfmac is an > upstream driver), please? I took a look at > brcmf_netdev_set_mac_address and I'm not sure what may be missing > there. I did report it to Arend; see "brcmfmac MAC address change delay and 500ms down delay" from 2016-09-15 on linux-wireless@. He then sent a patch which got committed as 8fa5fdec09cd379c9ecb8972f344f8f308e0ccf3 "brcmfmac: remove worker from .ndo_set_mac_address() callback" and should be in 4.9 and later kernels. Dan _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
