Is wpasupplicant 0.7.3-6 compatible with 5Ghz band steering?

[Jouni Malinen]

On Sat, Mar 31, 2012 at 11:24:22AM -0700, Marc MERLIN wrote:
> I was surprised that I had to use it to connect to an unencrypted
> network. I thought the driver by itself would enumerate the APs available
> and pick the best one.
> When signal strength dipped too low, I thought the driver would then itself
> rescan and find the next best AP with best signal.

Some drivers have that capability, but the mac80211-based drivers
(including the driver you used here) expect this to be done in user
space.

> However, if I didn't use wpa_supplicant and just used iwconfig to connect
> (again, this is an unencrypted network, so I can do that), I noticed the
> driver picked a crappy and far away 2.4Ghz signal (30/70) instead of the AP
> it was sitting right next to.

The cfg80211 capability to allow basic iwconfig functionality for
backwards compatibility is pretty limited.

> So, does it mean that the driver is too dumb to pick the best AP, and it
> does require wpa_supplicant to enumerate the APs and pick the best one?

That's the design used in many Linux WLAN drivers.

> Then, do you have an idea why wpa_supplicant would forcibly disconnect from
> a 5Ghz 70/70 signal to go seek a 2.4Ghz signal?

The 2.4 GHz signal was likely reported with stronger signal strength.
The 70/70 part is not that helpful since the exact meaning of the signal
quality is not really defined that well..

> Is it hardcoded to always pick 2.4Ghz if it finds it? 

No.

> Is disconnecting from 5Ghz to connect to 2.4Ghz even though auth was denied
> on 2.4 a bug, or a problem in the protocol?

It's not a bug - 2.4 GHz band can certainly be used even if an AP there
rejects association. The blacklist mechanism in scan processing marks
such APs in a way that allows the other APs to be selected when a
specific AP (BSS) is detected to reject connection.

The key part here is that the newer wpa_supplicant versions (at least
when used with the nl80211 driver interface) can handle this type of
forced load balancing/band steering much more quickly. In addition, they
require quite a bit larger difference in the signal strength before
trying to roam to a new AP in case the current one has reasonable signal
strength. In addition, 5 GHz APs are giving higher priority in BSS
selection.

> And to get the basics right: does linux wireless actually need
> wpa_supplicant to find the closest AP and manage handoffs when moving
> laptops around? Does it mean the driver can't do it itself, or as well?

This is done in user space with mac80211-based drivers.

> Ok, it seems that the  debian unstable package, 0.7.3-6,
> http://packages.debian.org/sid/i386/wpasupplicant
> does support this already, it's running fine.
> /sbin/wpa_supplicant -u -onl80211 -O/var/run/wpa_supplicant -f /var/log/wpa_supplicant.log
> 
> So it seems that my version already supports the new interface.

Maybe so, but it does not have the large set of improvements I described
above.. There was a reason for me pointing to the latest snapshot
instead of 0.7.3.

> Now, this problem will likely affect a bunch of ubuntu laptops at work
> (lucid or precise) and it's not very practical for me to go and give them
> all git checkout code, although that can be done if it's the only resort.

Maybe so, but if you want to get this working better, you will need to
update wpa_supplicant. I'm not sure whether there are debian packages
based on 1.0 release candidates somewhere; if yes, those should be
fine, too.

> Can you briefly explain how changing the control interface helps in this
> case?

The roaming improvements (avoid extra scans, react more quickly to
disconnection, etc.) were done mainly with nl80211 in mind. The other
parts (BSS selection behavior) is somewhat more independent of wext vs.
nl80211, but development and most of the testing has been done with
nl80211.

> Are you hopeful that new communication interface will stop telling the
> driver to disconnect from 5Ghz and back to 2.4Ghz, assuming that's what's
> going on?

No - the other changes handle that.

-- 
Jouni Malinen                                            PGP id EFC895FA