After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627571 - [enh] Make NM prefer 80211a (5GHz) networks
[enh] Make NM prefer 80211a (5GHz) networks
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: nm-applet
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-08-21 14:48 UTC by Matthias Uschok
Modified: 2015-08-21 08:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Uschok 2010-08-21 14:48:04 UTC
WLAN being pretty common these days tends to lead to overfull 80211g (2.4GHZ) networks in companies/universities. As most companies/universities offer parallel 80211g and 80211a networks using the same SSID. In my experience, the 80211a networks a way less crowded than the 80211g nets. Therefore I would like to see an option that lets NM prefer the former. One possible solution could be to have different entries for those networks appear in the nm-applet. That way, a user could even prefer the 80211g network, in case that network is less crowded eventually.
Comment 1 Matthias Uschok 2010-08-21 14:50:47 UTC
Oops: Cancel "As" in the second sentence.
Comment 2 Dan Williams 2010-08-24 15:45:25 UTC
Yeah, though unfortunately we can't do this yet because the necessary bits of wpa_supplicant aren't there yet to prefer 5GHz networks if the SSIDs are the same. We'll work on adding this to the supplicant and then we can add the necessary bits to NM itself.
Comment 3 Lukas Märdian 2011-10-26 10:13:12 UTC
Is this still not yet implemented in wpa_supplicant?

I found a network-manager option: 802-11-wireless/band=a but NetworkManager seems to ignore this.
Comment 4 Bernhard Schmidt 2012-05-28 13:04:39 UTC
A patch has gone into wpa_supplicant 1.0 which makes it slightly prefer 5Ghz networks. At least in my case it seems to be enough.

http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=577db0aedd9461b8d0beb5d6fc323970cfa60b07

Not configurable though.
Comment 5 Dan Williams 2014-03-10 15:16:31 UTC
See the dcbw/wifi-band branch for band-locking to 2.4 or 5GHz networks, using the 802-11-wireless/band property.
Comment 6 Dan Winship 2014-03-24 14:13:25 UTC
>+#define TWO_GHZ_FREQS  "2412,2417,2422,2427,2432,2437,2442,2447,2452,2457,2462,2467,2472,2484"
>+#define FIVE_GHZ_FREQS "4915,4920,4925,4935,4940,4945,4960,4980,5035,5040,5045,5055,5060,5080," \

Ugh. There's no better way to do this?

The docs for NMSettingWireless:band say "This setting depends on specific driver capability and may not work with all drivers." Is that still true?

Also, FWIW, ifcfg-rh doesn't seem to allow specifying band.
Comment 7 Thomas Haller 2014-03-24 19:54:56 UTC
(looks correct to me)
Comment 8 Dan Williams 2014-03-24 22:43:16 UTC
(In reply to comment #6)
> >+#define TWO_GHZ_FREQS  "2412,2417,2422,2427,2432,2437,2442,2447,2452,2457,2462,2467,2472,2484"
> >+#define FIVE_GHZ_FREQS "4915,4920,4925,4935,4940,4945,4960,4980,5035,5040,5045,5055,5060,5080," \
> 
> Ugh. There's no better way to do this?

Not really, upstream has rejected a generic band setting a couple times.  This is the upstream-suggested solution for now.

> The docs for NMSettingWireless:band say "This setting depends on specific
> driver capability and may not work with all drivers." Is that still true?

Yes, if the firmware controls roaming (non-mac80211 drivers, mostly) then the frequency thing here will not work.  When using mac80211/softmac drivers the supplicant controls the roaming decision, and if you give it a list of frequencies for a network, the supplicant just ignores any candidate APs that are outside the frequencies specified.

> Also, FWIW, ifcfg-rh doesn't seem to allow specifying band.

Pushed a fix for that.
Comment 9 Dan Winship 2014-03-25 14:59:38 UTC
(In reply to comment #8)
> (In reply to comment #6)
> > >+#define TWO_GHZ_FREQS  "2412,2417,2422,2427,2432,2437,2442,2447,2452,2457,2462,2467,2472,2484"
> > >+#define FIVE_GHZ_FREQS "4915,4920,4925,4935,4940,4945,4960,4980,5035,5040,5045,5055,5060,5080," \
> > 
> > Ugh. There's no better way to do this?
> 
> Not really, upstream has rejected a generic band setting a couple times.  This
> is the upstream-suggested solution for now.

OK. Eventually it would be nice to only hardcode the list of frequencies in one place though. (The complete list also appears in nm-utils.c, and the max/min values appear in a few other places.)

> > Also, FWIW, ifcfg-rh doesn't seem to allow specifying band.
> 
> Pushed a fix for that.

Looks good
Comment 10 Dan Williams 2014-03-26 03:45:10 UTC
merged
Comment 11 Jiri Klimes 2015-08-18 07:57:16 UTC
wpa_supplicant requires space-separated list of frequences in 'freq_list' option. Otherwise it won't parse it and it won't work (wpa_config_parse_freqs()).

I have pushed fixes to jk/freq-list-bgo627571 branch.
Comment 12 Thomas Haller 2015-08-18 08:12:31 UTC
(In reply to Jiri Klimes from comment #11)
> wpa_supplicant requires space-separated list of frequences in 'freq_list'
> option. Otherwise it won't parse it and it won't work
> (wpa_config_parse_freqs()).
> 
> I have pushed fixes to jk/freq-list-bgo627571 branch.

The first commit LGTM.


Why did you add nm_utils_wifi_.ghz_freqs()?
The are public API, but I think that the exposed format of a space-separated string is not great to consume. If there is really a need for such a function, then it should expose a_table and bg_table directly:

const struct cf_pair *
nm_utils_wifi_5ghz_freqs(guint *out_len)
{
    if (out_len)
        *out_len = G_N_ELEMENTS(bg_table) - 1;
    return bg_table;
}

But then, is that need at all (as public API)?

IMO the code duplication of having bg_table and FIVE_GHZ_FREQS is acceptable, because these lists are very static. You only have to get it right *once*.
Comment 13 Jiri Klimes 2015-08-18 11:00:18 UTC
(In reply to Thomas Haller from comment #12)
> (In reply to Jiri Klimes from comment #11)
> > wpa_supplicant requires space-separated list of frequences in 'freq_list'
> > option. Otherwise it won't parse it and it won't work
> > (wpa_config_parse_freqs()).
> > 
> > I have pushed fixes to jk/freq-list-bgo627571 branch.
> 
> The first commit LGTM.
> 
> 
> Why did you add nm_utils_wifi_.ghz_freqs()?
> The are public API, but I think that the exposed format of a space-separated
> string is not great to consume. If there is really a need for such a
> function, then it should expose a_table and bg_table directly:
> 
> const struct cf_pair *
> nm_utils_wifi_5ghz_freqs(guint *out_len)
> {
>     if (out_len)
>         *out_len = G_N_ELEMENTS(bg_table) - 1;
>     return bg_table;
> }
> 
> But then, is that need at all (as public API)?
> 
> IMO the code duplication of having bg_table and FIVE_GHZ_FREQS is
> acceptable, because these lists are very static. You only have to get it
> right *once*.

It depends on the client what format is regarded useful. Maybe an array of the frequences would be better. The main reason for introducing the function was code de-duplication. However, the functions may also be useful for clients.
What do others think?

I have added a new commit to only lock to a channel:
wifi: also support locking connections to a channel within a band (bgo #627571)
Comment 14 Thomas Haller 2015-08-19 11:15:05 UTC
(In reply to Jiri Klimes from comment #13)

> I have added a new commit to only lock to a channel:
> wifi: also support locking connections to a channel within a band (bgo
> #627571)

The last commit LGTM
Comment 15 Dan Williams 2015-08-19 15:01:54 UTC
> libnm: add utility functions for getting 2.4 GHz an 5 GHz Wi-Fi frequences

I think adding libnm functions is fine since other tools might want to use them for the UI.  However, I think if we expose them, we should expose them as a const guint const * array or something, instead of a string.  That allows clients like nmcli or nm-conneciton-editor or GNOME SHell to more easily use the frequency data in the UI.  These tools can then transform it as they see fit.  NM could just have a static const char * internally where we transform the array to a string for the supplicant once.

> wifi: also support locking connections to a channel within band (bgo #627571)

Both of these hunks require band != NULL, so lets just put them into the same if:

if (band) {
    if (channel) {
    } else {
    }
}
Comment 16 Jiri Klimes 2015-08-20 09:39:08 UTC
(In reply to Dan Williams from comment #15)
> > libnm: add utility functions for getting 2.4 GHz an 5 GHz Wi-Fi frequences
> 
> I think adding libnm functions is fine since other tools might want to use
> them for the UI.  However, I think if we expose them, we should expose them
> as a const guint const * array or something, instead of a string.  That
> allows clients like nmcli or nm-conneciton-editor or GNOME SHell to more
> easily use the frequency data in the UI.  These tools can then transform it
> as they see fit.  NM could just have a static const char * internally where
> we transform the array to a string for the supplicant once.
> 

Done.

> > wifi: also support locking connections to a channel within band (bgo #627571)
> 
> Both of these hunks require band != NULL, so lets just put them into the
> same if:
> 
> if (band) {
>     if (channel) {
>     } else {
>     }
> }

Done.
Comment 17 Beniamino Galvani 2015-08-20 13:06:14 UTC
> libnm: add utility functions for getting 2.4 GHz and 5 GHz Wi-Fi frequences

Pushed a trivial documentation fixup.

The branch looks good to me.
Comment 18 Dan Williams 2015-08-20 14:03:56 UTC
Any particular reason to make the freq arrays 'int' rather than guint or something unsigned?   Besides that, LGTM.
Comment 19 Jiri Klimes 2015-08-21 08:08:46 UTC
(In reply to Beniamino Galvani from comment #17)
> > libnm: add utility functions for getting 2.4 GHz and 5 GHz Wi-Fi frequences
> 
> Pushed a trivial documentation fixup.
> 
Merged, thanks.

(In reply to Dan Williams from comment #18)
> Any particular reason to make the freq arrays 'int' rather than guint or
> something unsigned?   Besides that, LGTM.

Changed to guint.

Commits in master:
4dd6632 merge: Wi-Fi band/channel locking fixes (bgo #627571)
c0f6725 wifi: also support locking connections to a channel within band (bgo #627571)
3c12223 supplicant: use util functions for Wi-Fi frequencies
1a6b631 libnm: add utility functions for getting 2.4 GHz and 5 GHz Wi-Fi frequencies
4fe6bdc supplicant: wpa_supplicant wants space-separated list in freq_list (bgo #627571)

Backported to nm-1-0 (for 1.0.6):
7b47b5e merge: Wi-Fi band/channel locking fixes (bgo #627571)
d80f1fe wifi: also support locking connections to a channel within band (bgo #627571)
b19f3d9 supplicant: use util functions for Wi-Fi frequencies
77bf69c libnm: add utility functions for getting 2.4 GHz and 5 GHz Wi-Fi frequencies
c8b5b5e supplicant: wpa_supplicant wants space-separated list in freq_list (bgo #627571)