[Bisected] Connection failures when using wl driver (Broadcom) since rev. f2a6ad01

[Rafał Miłecki]

On 5 January 2017 at 18:24, Dan Williams <dcbw at redhat.com> wrote:
> On Wed, 2017-01-04 at 22:24 +0100, Rafał Miłecki wrote:
>> On 4 January 2017 at 17:25, Dan Williams <dcbw at redhat.com> 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 at .  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ł