On 5 January 2017 at 18:24, Dan Williams <dcbw@xxxxxxxxxx> wrote: > 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. Oh, that clarifies things, thanks! -- Rafał _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
