[PATCH] wpa_supplicant: Prefer 5 GHz networks over 2.4 GHz networks.

[Sam Leffler]

On Tue, Aug 16, 2011 at 3:50 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2011-08-16 at 10:43 -0700, Sam Leffler wrote:
>> On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams <dcbw at redhat.com> wrote:
>> > On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:
>> >> In scan.c, merge a channel's noise value into the scan results. ?When comparing
>> >> scan results, compute the signal-to-noise ratio and use it when available.
>> >> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR is
>> >> relatively close to the other network's.
>> >
>> > Honestly I'd rather have something like a "bands" option on a
>> > per-netblock basis, so you could do this:
>> >
>> > bands=5
>> > bands=5,2
>> > bands=2,5
>> > bands=2
>> >
>> > ie, the connection manager can set whichever band it prefers, or leave
>> > it out entirely to let the supplicant do whatever it's already doing.
>> > The problem with micro-optimizations like this are that they often
>> > break, and they aren't necessarily clear. ?I'd advocate for simpler,
>> > clearer rules here, with behavior set by the connection manager, rather
>> > than continually more complicated matching rules in the supplicant
>> > itself...
>>
>> I'm trying to understand how this would be used. ?The point of Gary's
>> change is to prefer the 5GHz band only when two AP's have equivalent
>> signal quality. (5GHz is considered better because it has
>> non-overlapping channels, less likely to have interference, etc.)
>> This is meant to improve the algorithm by which a BSS is selected.
>
> Yeah, I guess that's different than I'm proposing. ?But making this
> decision is still a policy decision that I'm not sure should be done in
> the supplicant.

supplicant already imposes many policies; I think this one is minor in
comparison.

>
>> Also, specifying a preference on a per-netblock basis seems odd; when
>> would you want to control band preferences only for a specific SSID?
>
> I've had this request come up periodically. ?If your institution uses
> the same SSID between the 5GHz and 2.4GHz wifi networks, but you'd like
> to always be on the 5GHz segment because it's less loaded. ?But other
> places you may not want to be on the 5GHz network. ?It really is a
> per-SSID (ie per network) preference.

Using band preference to determine channel congestion is a mistake
IMO.  You can add a metric to measure the channel congestion and this
seems like a fine thing to do--but separately.

>
>> You can lock down a netblock using bssid= and assign priority though
>> it might be painful to list all the AP's in an ESS. ?If we really want
>> to add this complexity it seems like it belongs per-interface or
>> global (or at compile-time).
>
> I disagree. ?It's not global to the entire decision, it's specific to
> the netblock. ?You may not always want to prefer 5GHz networks
> everywhere you are. ?The problem with the freq= parameter is that to
> achieve this behavior you'd have to list *all* the frequencies in the
> 5GHz and 2.4GHz range, while using bssid= is a no-go because the
> situation where you want this behavior is one where there are a ton of
> APs around.

It sounds like we should just split the "prefer 5GHz" thing out.  I
don't think you're going to be happy w/ any configuration knobs for
the situations you're thinking of.  Instead you need to add more data
to make a more informed decision.

-Sam