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

[Marc MERLIN]

Thank you very much for answering my questions.

On Sat, Mar 31, 2012 at 09:47:00PM +0300, Jouni Malinen wrote:
> Some drivers have that capability, but the mac80211-based drivers
> (including the driver you used here) expect this to be done in user
> space.

Thanks for clearing that up. I could have sworn having seen this in past
times.

> > 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.

That makes sense, but I still think I hit a bug and I'm hopeful the new code
you pointed to will fix that.

My original logs showed how I was connected to a 70/70 AP, how it tried to
auth with a 2.4GHz AP, failed, and then disconnected me from my perfectly
good working AP:
> 20:01:00 kernel: [ 8765.107876] cfg80211: Found new beacon on frequency: 5805 MHz (Ch 161) on phy0
> 20:01:01 wpa_supplicant[12458]: Trying to authenticate with 00:24:6c:63:56:20 (SSID='GoogleGuest' freq=2437
MHz)
> 20:01:01 kernel: [ 8765.376215] wlan0: direct probe to 00:24:6c:63:56:20 (try 1/3)
> 20:01:01 NetworkManager[12447]: <info> (wlan0): supplicant interface state: completed -> authenticating
> 20:01:01 kernel: [ 8765.576037] wlan0: direct probe to 00:24:6c:63:56:20 (try 2/3)
> 20:01:01 kernel: [ 8765.776072] wlan0: direct probe to 00:24:6c:63:56:20 (try 3/3)
> 20:01:01 kernel: [ 8765.976059] wlan0: direct probe to 00:24:6c:63:56:20 timed out
> 20:01:11 kernel: [ 8776.116832] wlan0: deauthenticating from 00:24:6c:63:56:31 by local choice (reason=2)
> 20:01:11 kernel: [ 8776.133580] cfg80211: All devices are disconnected, going to restore regulatory settings

Does it make sense that it should not have done this?
'deauthenticating from 00:24:6c:63:56:31 by local choice (reason=2)'

Yes, I will try this again with the new git code when I get back to work and
report back :)

> 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.

That's great. So it sounds like while I don't quite understand why I was
disconnected above, the changes you describe will most likely ensure that I
won't get in this situation anyway.

> > 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.

Understood, will get git now.

> 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.

I didn't see any, but I can build some if necessary. I was hoping that there
would be a simpler workaround, up to even disabling 2.4Ghz altogether on those
laptops, but I haven't found a way to disable 2.4Ghz for a connection, or
even altogether in the module, but that does not seem possible.
I also did not find an option in wpa_supplicant to say 'ignore all 2.4Ghz
APs for this essid', so it sounds like we'll just have to upgrade them all.

Thank you for your answers and your software.
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/