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

[Dan Williams]

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

> > 
> > 
> > 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
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap