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

[Evgenii Shatokhin]

On 19.12.2016 18:53, Dan Williams wrote:
> On Mon, 2016-12-19 at 15:11 +0300, Evgenii Shatokhin wrote:
>> On 19.12.2016 14:00, Jouni Malinen wrote:
>>>
>>> On Mon, Dec 19, 2016 at 12:28:45PM +0300, Evgenii Shatokhin wrote:
>>>>
>>>> After update of wpa_supplicant from v.2.4 to v2.6, the system can
>>>> no
>>>> longer connect to WiFi networks. The problem persists from the
>>>> current version of wpa_supplicant from git (rev. aaa9c60b) as
>>>> well.
>>>>
>>>> NetworkManager shows "Configuring interface" for the chosen SSID
>>>> and
>>>> after some time just tells that the connection failed
>>>> ("disconnected")
>>>>
>>>> The problem only happens when I use the proprietary driver (wl)
>>>> from
>>>> Broadcom for the WiFi adapter. Everything seems to be OK with the
>>>> opensource driver though.
>>>>
>>>> The log of wpa_supplicant is attached.
>>>
>>> What kind of changes are there in wpa_supplicant on top of the
>>> actually
>>> released versions? This logs show following line:
>>>
>>> properties_get_or_set: Set(PreassocMacAddr)
>>
>> No additional patches, I just built the code from the git repo,
>> master
>> branch. The configuration is attached, if that matters.
>
> I would take this discussion to the NetworkManager list for now.
>   Randomized MAC addresses and TLS v1.2 have been problematic for a
> couple of reasons.
>
> First we've found a number of drivers (like brcmfmac) that don't work
> with randomized MAC addresses because they don't actually set that
> address immediately, but defer it to a workqueue for later and return
> success.  That causes some issues between NM and the supplicant's event
> processing behavior when the MAC address finally does change.  I
> wouldn't be surprised if the wl driver code does the same thing.
>
> TLS v1.2 has also been problematic in some cases, but I would suspect
> randomized MAC addresses first.
>
> Anyway, better to take this to the NM list to root-cause the issue and
> if it does turn out to be the supplicant, we can come back around.
>
> Dan

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.

I should have guessed earlier the culprit is in NM, that would save some 
time.

If the problem shows up again, I will report it to the NM's developers 
like you suggest.

Anyway, thanks to everyone for explanations and quick replies.

>
>>>
>>>
>>> while PreassocMacAddr does not seem to exist in hostap.git version
>>> at
>>> all.. Please also note that this configures random MAC address use
>>> which
>>> is failing in the debug log apparently due to driver not supporting
>>> it.
>>>
>>>>
>>>> Version 2.4 worked OK with both drivers.
>>>
>>> Using random MAC addresses?
>>
>> I made no changes in the connection settings.
>>
>> I just checked out tag hostap_2_4 in git repo, copied the attached
>> config file to .config, then - cd wpa_supplicant && make. Then as
>> follows:
>>
>> systemctl stop wpa_supplicant
>> cp wpa_supplicant wpa_cli wpa_passphrase /usr/sbin/
>> systemctl start wpa_supplicant
>>
>> iw dev wlan0 scan # to force the scan for the NM to see the
>> connections
>>
>> After that, I selected the appropriate SSID in NM and the connection
>> was
>> established.
>>
>> Checkout 'master' again, do the same steps => connection failure.
>>
>>>
>>>
>>>>
>>>> git bisect pointed to the following commit as the first "bad"
>>>> one:
>>>> commit f2a6ad01a943103c658de5721c2d7f7e91ee7fa4
>>>> Author: Jouni Malinen <j at w1.fi>
>>>> Date:   Sun Nov 29 18:59:27 2015 +0200
>>>>
>>>>       TLS client: Add support for server certificate probing
>>>
>>> I would find it very unlikely for this commit to have anything to
>>> do
>>> with this issue.. Are you even building in the code this touches
>>> (i.e.,
>>> CONFIG_TLS=internal)? In any case, that functionality is not used
>>> before
>>> the association is established.
>>>
>>>>
>>>> dbus: org.freedesktop.DBus.Properties.Set
>>>> (/fi/w1/wpa_supplicant1/Interfaces/1) [ssv]
>>>> properties_get_or_set: Set(PreassocMacAddr)
>>>> preassoc_mac_addr=1
>>>
>>> This functionality does not exist in upstream version over D-Bus
>>> interface..
>>
>> Could it be that NetworkManager messes with these things somehow?
>> Because, I used the original, unpached code for testing.
>>
>> By the way, if that matters, the following service file is used for
>> wpa_supplicant in that system:
>>
>> -----------------
>> [Unit]
>> Description=WPA Supplicant daemon
>> Before=network.target
>> After=syslog.target
>>
>> [Service]
>> Type=dbus
>> BusName=fi.w1.wpa_supplicant1
>> EnvironmentFile=-/etc/sysconfig/wpa_supplicant
>> ExecStart=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant.conf
>> $INTERFACES $DRIVERS $OTHER_ARGS
>>
>> [Install]
>> WantedBy=multi-user.target
>> -----------------
>>
>> /etc/sysconfig/wpa_supplicant:
>> -----------------
>> INTERFACES=""
>> DRIVERS=""
>> OTHER_ARGS="-u -f /var/log/wpa_supplicant.log -P
>> /var/run/wpa_supplicant.pid"
>> -----------------
>>
>> /etc/wpa_supplicant.conf - the same as
>> wpa_supplicant/wpa_supplicant.conf in the git repo but with
>> network={}
>> blocks commented out.
>>
>> No mention of PreassocMacAddr or similar stiff here which makes me
>> think
>> it is set by something else.
>>
>>>
>>>
>>>>
>>>> wlan0: Starting radio work 'scan'@0x1fb5440 after 0.000057 second
>>>> wait
>>>> Could not set interface wlan0 hwaddr: Too many open files in
>>>> system
>>>> nl80211: failed to set_mac_addr for wlan0 to 96:a4:b3:79:fd:89
>>>> wlan0: Failed to set random MAC address
>>>> wlan0: Failed to assign random MAC address for a scan
>>>
>>> and this is where that operation enabled by preassoc_mac_addr=1 is
>>> failing in the driver..
>>>
>>>>
>>>> dbus: org.freedesktop.DBus.Properties.Set
>>>> (/fi/w1/wpa_supplicant1/Interfaces/1) [ssv]
>>>> properties_get_or_set: Set(MacAddr)
>>>> mac_addr=0
>>>
>>> and that one does not exists either in upstream..
>>>
>>>
>>> In other words, it looks like there are some custom changes in
>>> wpa_supplicant and those changes are in the area that the used
>>> driver
>>> does not support. I'd test what happens with that functionality
>>> (random
>>> MAC address) disabled.
>>>
>>
>> Hm, it looks like using random MAC addresses is not enabled in the
>> NM's
>> gui for that connection, but it could be a bug in the gui.
>>
>> I will try to hard-code the same MAC address as the device has, just
>> in
>> case. And/or try without NM to take it out of the question.
>>
>> Thanks for a quick reply, by the way.

Regards,
Evgenii