Is wpasupplicant 0.7.3-6 compatible with 5Ghz band steering?
Sat Mar 31 12:35:38 PDT 2012
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
Thanks for clearing that up. I could have sworn having seen this in past
> > 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: Trying to authenticate with 00:24:6c:63:56:20 (SSID='GoogleGuest' freq=2437
> 20:01:01 kernel: [ 8765.376215] wlan0: direct probe to 00:24:6c:63:56:20 (try 1/3)
> 20:01:01 NetworkManager: <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
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.
"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/
More information about the Hostap