Force use of 5GHz band

Force use of 5GHz band

[Jonas Große Sundrup]

Hi,

is there a way to force iwd to use the 5GHz flavor of a specific wifi?
I am aware of BandModifier5GHz, but even with setting this to 1000 I
still end up on the 2.5GHz band. That band specifically, however, is
unfortunately suspect for some stability issues I'm facing and hence I
would like to force iwd onto the 5GHz band to see if the problems still
occur. That proves to be difficult, of course, if iwd is picking the
2.5GHz band…

Even though I do see that iwd probably has the better insight into band
stability from a signal-strength point of view, any chance of
overruling iwd's internal mechanisms here? (Or should I just crank up
BandModifier5GHz by a couple of magnitudes?)


Thanks,
Jonas

Re: Force use of 5GHz band

[James Prestwood]

Hi Jonas,

On 9/14/23 10:44 AM, Jonas Große Sundrup wrote:
> Hi,
> 
> is there a way to force iwd to use the 5GHz flavor of a specific wifi?
> I am aware of BandModifier5GHz, but even with setting this to 1000 I
> still end up on the 2.5GHz band. That band specifically, however, is
> unfortunately suspect for some stability issues I'm facing and hence I
> would like to force iwd onto the 5GHz band to see if the problems still
> occur. That proves to be difficult, of course, if iwd is picking the
> 2.5GHz band…
> 
> Even though I do see that iwd probably has the better insight into band
> stability from a signal-strength point of view, any chance of
> overruling iwd's internal mechanisms here? (Or should I just crank up
> BandModifier5GHz by a couple of magnitudes?)

All we have now is BandModifier5GHz which is multiplied by the computed 
rank. The stock rank is based mainly on a data rate computation which is 
theoretical, but uses capabilities and signal strength to estimate.

1000 is pretty high, so essentially your 2.4GHz BSS's would need to have 
a rank 1000x larger than the 5Ghz ones. So either 5ghz is incredibly low 
signal, doesn't support HT/VHT, or maybe the IEs are malformed so the 
data rate isn't being computed correctly e.g. (defaulting to basic rates).

Do you have debug logs of the scan results?

> 
> 
> Thanks,
> Jonas
> 

Re: Force use of 5GHz band

[Jonas Große Sundrup]

Not right now, but if you give me a command that'd spit out what you
want to see, I'll get them.

Just iwd -d and then trigger a scan in iwctl?

On Thu, 2023-09-14 at 11:06 -0700, James Prestwood wrote:
> Hi Jonas,
> 
> On 9/14/23 10:44 AM, Jonas Große Sundrup wrote:
> > Hi,
> > 
> > is there a way to force iwd to use the 5GHz flavor of a specific
> > wifi?
> > I am aware of BandModifier5GHz, but even with setting this to 1000
> > I
> > still end up on the 2.5GHz band. That band specifically, however,
> > is
> > unfortunately suspect for some stability issues I'm facing and
> > hence I
> > would like to force iwd onto the 5GHz band to see if the problems
> > still
> > occur. That proves to be difficult, of course, if iwd is picking
> > the
> > 2.5GHz band…
> > 
> > Even though I do see that iwd probably has the better insight into
> > band
> > stability from a signal-strength point of view, any chance of
> > overruling iwd's internal mechanisms here? (Or should I just crank
> > up
> > BandModifier5GHz by a couple of magnitudes?)
> 
> All we have now is BandModifier5GHz which is multiplied by the
> computed 
> rank. The stock rank is based mainly on a data rate computation which
> is 
> theoretical, but uses capabilities and signal strength to estimate.
> 
> 1000 is pretty high, so essentially your 2.4GHz BSS's would need to
> have 
> a rank 1000x larger than the 5Ghz ones. So either 5ghz is incredibly
> low 
> signal, doesn't support HT/VHT, or maybe the IEs are malformed so the
> data rate isn't being computed correctly e.g. (defaulting to basic
> rates).
> 
> Do you have debug logs of the scan results?
> 
> > 
> > 
> > Thanks,
> > Jonas
> > 

Re: Force use of 5GHz band

[James Prestwood]

On 9/14/23 11:13 AM, Jonas Große Sundrup wrote:
> Not right now, but if you give me a command that'd spit out what you
> want to see, I'll get them.
> 
> Just iwd -d and then trigger a scan in iwctl?

Yep that would do it.

> 
> On Thu, 2023-09-14 at 11:06 -0700, James Prestwood wrote:
>> Hi Jonas,
>>
>> On 9/14/23 10:44 AM, Jonas Große Sundrup wrote:
>>> Hi,
>>>
>>> is there a way to force iwd to use the 5GHz flavor of a specific
>>> wifi?
>>> I am aware of BandModifier5GHz, but even with setting this to 1000
>>> I
>>> still end up on the 2.5GHz band. That band specifically, however,
>>> is
>>> unfortunately suspect for some stability issues I'm facing and
>>> hence I
>>> would like to force iwd onto the 5GHz band to see if the problems
>>> still
>>> occur. That proves to be difficult, of course, if iwd is picking
>>> the
>>> 2.5GHz band…
>>>
>>> Even though I do see that iwd probably has the better insight into
>>> band
>>> stability from a signal-strength point of view, any chance of
>>> overruling iwd's internal mechanisms here? (Or should I just crank
>>> up
>>> BandModifier5GHz by a couple of magnitudes?)
>>
>> All we have now is BandModifier5GHz which is multiplied by the
>> computed
>> rank. The stock rank is based mainly on a data rate computation which
>> is
>> theoretical, but uses capabilities and signal strength to estimate.
>>
>> 1000 is pretty high, so essentially your 2.4GHz BSS's would need to
>> have
>> a rank 1000x larger than the 5Ghz ones. So either 5ghz is incredibly
>> low
>> signal, doesn't support HT/VHT, or maybe the IEs are malformed so the
>> data rate isn't being computed correctly e.g. (defaulting to basic
>> rates).
>>
>> Do you have debug logs of the scan results?
>>
>>>
>>>
>>> Thanks,
>>> Jonas
>>>
> 

Re: Force use of 5GHz band

[Jonas Große Sundrup]

On Thu, 2023-09-14 at 11:16 -0700, James Prestwood wrote:
> Yep that would do it.

automatically quick scan upon start: https://p.nnev.de/12646

explicit scan triggered via "station wifi scan":
https://p.nnev.de/12647

anything insightful in there?


Thanks,
Jonas

Re: Force use of 5GHz band

[James Prestwood]

On 9/14/23 11:22 AM, Jonas Große Sundrup wrote:
> On Thu, 2023-09-14 at 11:16 -0700, James Prestwood wrote:
>> Yep that would do it.
> 
> automatically quick scan upon start: https://p.nnev.de/12646
> 
> explicit scan triggered via "station wifi scan":
> https://p.nnev.de/12647
> 
> anything insightful in there?

A value of 1000 should definitely work... Are you sure the syntax is 
right inside main.conf:

[Rank]
BandModifier5Ghz=1000

(I noticed in your original email you had the 'h' capitalized in 5Ghz)

> 
> 
> Thanks,
> Jonas

Re: Force use of 5GHz band

[Jonas Große Sundrup]

On Thu, 2023-09-14 at 11:33 -0700, James Prestwood wrote:
> A value of 1000 should definitely work... Are you sure the syntax is 
> right inside main.conf:
> 
> [Rank]
> BandModifier5Ghz=1000
> 
> (I noticed in your original email you had the 'h' capitalized in
> 5Ghz)

Oh, no I didn't, it was GHz in my configfile, probably my brain typed
the spelling of the actual unit… thanks, I'm on 5GHz now! :)

(Feature Request: also accept "5GHz" as spelling, given that's the
correct unit spelling? 😅)

Thanks so much!

Jonas

Re: Force use of 5GHz band

[Denis Kenzior]

Hi James,

On 9/14/23 13:33, James Prestwood wrote:
> 
> On 9/14/23 11:22 AM, Jonas Große Sundrup wrote:
>> On Thu, 2023-09-14 at 11:16 -0700, James Prestwood wrote:
>>> Yep that would do it.
>>
>> automatically quick scan upon start: https://p.nnev.de/12646
>>
>> explicit scan triggered via "station wifi scan":
>> https://p.nnev.de/12647
>>
>> anything insightful in there?
> 
> A value of 1000 should definitely work... Are you sure the syntax is right 
> inside main.conf:

Careful about using high factors like this.  Right now the rank is computed 
using a double, but truncated to a uint32_t and clamped to USHRT_MAX / uint16_t. 
  This works fine, but the FT roaming calculation is a bit more careless.  Could 
lead to very funny results.

We may be better off introducing 2.4GHz factor and suggesting using a 0.0 
multiplier to turn bands off.  Or add an explicit setting.

Regards,
-Denis

Re: Force use of 5GHz band

[Denis Kenzior]

Hi Jonas,

> 
> (Feature Request: also accept "5GHz" as spelling, given that's the
> correct unit spelling? 😅)

Yeah we really should.  Too bad we somehow screwed up the capitalization in this 
case and settings keys are case-sensitive.

Regards,
-Denis

Re: Force use of 5GHz band

[James Prestwood]

Hi Denis,

On 9/15/23 7:30 AM, Denis Kenzior wrote:
> Hi James,
> 
> On 9/14/23 13:33, James Prestwood wrote:
>>
>> On 9/14/23 11:22 AM, Jonas Große Sundrup wrote:
>>> On Thu, 2023-09-14 at 11:16 -0700, James Prestwood wrote:
>>>> Yep that would do it.
>>>
>>> automatically quick scan upon start: https://p.nnev.de/12646
>>>
>>> explicit scan triggered via "station wifi scan":
>>> https://p.nnev.de/12647
>>>
>>> anything insightful in there?
>>
>> A value of 1000 should definitely work... Are you sure the syntax is 
>> right inside main.conf:
> 
> Careful about using high factors like this.  Right now the rank is 
> computed using a double, but truncated to a uint32_t and clamped to 
> USHRT_MAX / uint16_t.  This works fine, but the FT roaming calculation 
> is a bit more careless.  Could lead to very funny results.

I don't think FT uses that ranking factor, but either way yes some huge 
factor like that shouldn't be needed.

> 
> We may be better off introducing 2.4GHz factor and suggesting using a 
> 0.0 multiplier to turn bands off.  Or add an explicit setting.

I actually was thinking this would be nice. We actually don't even run a 
2.4ghz network at all so that would reduce extra scanning cycles, even 
if just a couple seconds. I'll go ahead and add support for 0.0 factors 
disabling the band, and add a 2.4 factor setting.

> 
> Regards,
> -Denis
> 

Re: Force use of 5GHz band

[James Prestwood]

On 9/15/23 7:35 AM, Denis Kenzior wrote:
> 
> Hi Jonas,
> 
>>
>> (Feature Request: also accept "5GHz" as spelling, given that's the
>> correct unit spelling? 😅)
> 
> Yeah we really should.  Too bad we somehow screwed up the capitalization 
> in this case and settings keys are case-sensitive.

The API is camel case, so I could see the argument the 'h' should be 
lower case. But I don't care either way, supporting both is easy enough 
to add.

> 
> Regards,
> -Denis

Re: Force use of 5GHz band

[Denis Kenzior]

Hi James,

>> Careful about using high factors like this.  Right now the rank is computed 
>> using a double, but truncated to a uint32_t and clamped to USHRT_MAX / 
>> uint16_t.  This works fine, but the FT roaming calculation is a bit more 
>> careless.  Could lead to very funny results.
> 
> I don't think FT uses that ranking factor, but either way yes some huge factor 
> like that shouldn't be needed.
> 

Right, but it uses another factor and truncates to a uint16_t.  So if you have 
USHRT_MAX as rank, multiply then truncate -> fun things happen.

>>
>> We may be better off introducing 2.4GHz factor and suggesting using a 0.0 
>> multiplier to turn bands off.  Or add an explicit setting.
> 
> I actually was thinking this would be nice. We actually don't even run a 2.4ghz 
> network at all so that would reduce extra scanning cycles, even if just a couple 
> seconds. I'll go ahead and add support for 0.0 factors disabling the band, and 
> add a 2.4 factor setting.

Excellent.

Regards,
-Denis

Re: Force use of 5GHz band

[Denis Kenzior]

Hi James,

On 9/15/23 09:44, James Prestwood wrote:
> On 9/15/23 7:35 AM, Denis Kenzior wrote:
>>
>> Hi Jonas,
>>
>>>
>>> (Feature Request: also accept "5GHz" as spelling, given that's the
>>> correct unit spelling? 😅)
>>
>> Yeah we really should.  Too bad we somehow screwed up the capitalization in 
>> this case and settings keys are case-sensitive.
> 
> The API is camel case, so I could see the argument the 'h' should be lower case. 
> But I don't care either way, supporting both is easy enough to add.

True, this is a bit of a grey area.  We don't use strict camel case for 
abbreviations in (some of?) our settings (IPv4, DNSList, APRange, etc).

But yeah, capability for settings to retrieve keys in case-insensitive manner 
would be useful.

Regards,
-Denis

Re: Force use of 5GHz band

[James Prestwood]

Hi Denis,

On 9/15/23 7:47 AM, Denis Kenzior wrote:
> Hi James,
> 
>>> Careful about using high factors like this.  Right now the rank is 
>>> computed using a double, but truncated to a uint32_t and clamped to 
>>> USHRT_MAX / uint16_t.  This works fine, but the FT roaming 
>>> calculation is a bit more careless.  Could lead to very funny results.
>>
>> I don't think FT uses that ranking factor, but either way yes some 
>> huge factor like that shouldn't be needed.
>>
> 
> Right, but it uses another factor and truncates to a uint16_t.  So if 
> you have USHRT_MAX as rank, multiply then truncate -> fun things happen.
> 
>>>
>>> We may be better off introducing 2.4GHz factor and suggesting using a 
>>> 0.0 multiplier to turn bands off.  Or add an explicit setting.
>>
>> I actually was thinking this would be nice. We actually don't even run 
>> a 2.4ghz network at all so that would reduce extra scanning cycles, 
>> even if just a couple seconds. I'll go ahead and add support for 0.0 
>> factors disabling the band, and add a 2.4 factor setting.
> 
> Excellent.

How would you prefer I do this? We've got quite a few modules using scan 
APIs so I question if we want to filter the frequencies before calling 
scan_*

If we filter in scan.c and call back as if the scan returned no results 
we shouldn't need to touch anything except scan.c. The downside is its a 
bit of wasted work doing this since we have to create requests and work 
items for nothing, but the alternative of adding this specific logic to 
each module using scan calls seems worse IMO, what do you think?

> 
> Regards,
> -Denis

Re: Force use of 5GHz band

[Denis Kenzior]

Hi James,

> 
> How would you prefer I do this? We've got quite a few modules using scan APIs so 
> I question if we want to filter the frequencies before calling scan_*

We should be doing that already, no?  Any code that specifies scan frequencies 
in some way should be aware of wiphy band capability and regdom.

> 
> If we filter in scan.c and call back as if the scan returned no results we 
> shouldn't need to touch anything except scan.c. The downside is its a bit of 

I really rather not generate dummy/bogus callbacks.  That just pollutes debug 
logs and makes the code hard to follow.  Station would be most affected here 
since it breaks up the 2.4Ghz band scan quite a bit.

If 2.4 is turned off, it should just skip those requests entirely.

> wasted work doing this since we have to create requests and work items for 
> nothing, but the alternative of adding this specific logic to each module using 
> scan calls seems worse IMO, what do you think?
> 

One thing to keep in mind is that some devices operate only on 2.4G.  For 
example WSC/WPS might only perform push button operations on 2.4 GHz band and 
not 5G.  Might be similar with DPP?  So for compatibility reasons maybe this 
should be a station-only feature?

Regards,
-Denis

Re: Force use of 5GHz band

[James Prestwood]

On 9/16/23 8:18 AM, Denis Kenzior wrote:
> Hi James,
> 
>>
>> How would you prefer I do this? We've got quite a few modules using 
>> scan APIs so I question if we want to filter the frequencies before 
>> calling scan_*
> 
> We should be doing that already, no?  Any code that specifies scan 
> frequencies in some way should be aware of wiphy band capability and 
> regdom.
> 
>>
>> If we filter in scan.c and call back as if the scan returned no 
>> results we shouldn't need to touch anything except scan.c. The 
>> downside is its a bit of 
> 
> I really rather not generate dummy/bogus callbacks.  That just pollutes 
> debug logs and makes the code hard to follow.  Station would be most 
> affected here since it breaks up the 2.4Ghz band scan quite a bit.
> 
> If 2.4 is turned off, it should just skip those requests entirely.
> 
>> wasted work doing this since we have to create requests and work items 
>> for nothing, but the alternative of adding this specific logic to each 
>> module using scan calls seems worse IMO, what do you think?
>>
> 
> One thing to keep in mind is that some devices operate only on 2.4G.  
> For example WSC/WPS might only perform push button operations on 2.4 GHz 
> band and not 5G.  Might be similar with DPP?  So for compatibility 
> reasons maybe this should be a station-only feature?

Yeah, keeping it station only is good with me. Only part that gets nasty 
are periodic scans. Since we scan the entire spectrum and specifying a 
frequency list will break the 6GHz logic we have... So for this I'll 
need to add support to split the scan request if explicit frequencies 
are provided, since periodic scans will need to include a (potentially) 
paired down list if the user disables them.

This could end up being useful though if e.g. a quick scan includes a 
6GHz channel and is able to scan it rather than falling back to a full scan.

> 
> Regards,
> -Denis
> 

Re: Force use of 5GHz band

[Alvin Šipraga]

On Thu, Sep 14, 2023 at 11:06:18AM -0700, James Prestwood wrote:
> Hi Jonas,
> 
> On 9/14/23 10:44 AM, Jonas Große Sundrup wrote:
> > Hi,
> > 
> > is there a way to force iwd to use the 5GHz flavor of a specific wifi?
> > I am aware of BandModifier5GHz, but even with setting this to 1000 I
> > still end up on the 2.5GHz band. That band specifically, however, is
> > unfortunately suspect for some stability issues I'm facing and hence I
> > would like to force iwd onto the 5GHz band to see if the problems still
> > occur. That proves to be difficult, of course, if iwd is picking the
> > 2.5GHz band…
> > 
> > Even though I do see that iwd probably has the better insight into band
> > stability from a signal-strength point of view, any chance of
> > overruling iwd's internal mechanisms here? (Or should I just crank up
> > BandModifier5GHz by a couple of magnitudes?)
> 
> All we have now is BandModifier5GHz which is multiplied by the computed
> rank. The stock rank is based mainly on a data rate computation which is
> theoretical, but uses capabilities and signal strength to estimate.
> 
> 1000 is pretty high, so essentially your 2.4GHz BSS's would need to have a
> rank 1000x larger than the 5Ghz ones. So either 5ghz is incredibly low
> signal, doesn't support HT/VHT, or maybe the IEs are malformed so the data
> rate isn't being computed correctly e.g. (defaulting to basic rates).

We had a request at the company to disable 2.4 GHz entirely as well, but I did
not want to completely disable it as some customers may not even have 5 GHz
infrastructure. My colleague Pedro drafted a patch which allows for the internal
BSS ranking to be normalized according to a required bitrate, so that 5 GHz
networks do not always out-compete 2.4 GHz networks. We found this worked well
together with the BandModifier option.

I have asked him to send the patch to the list, so please take a look. Might be
something of interest for upstream.

Kind regards,
Alvin

Re: Force use of 5GHz band

[James Prestwood]

Hi Alvin,

On 9/21/23 7:21 AM, Alvin Šipraga wrote:
> On Thu, Sep 14, 2023 at 11:06:18AM -0700, James Prestwood wrote:
>> Hi Jonas,
>>
>> On 9/14/23 10:44 AM, Jonas Große Sundrup wrote:
>>> Hi,
>>>
>>> is there a way to force iwd to use the 5GHz flavor of a specific wifi?
>>> I am aware of BandModifier5GHz, but even with setting this to 1000 I
>>> still end up on the 2.5GHz band. That band specifically, however, is
>>> unfortunately suspect for some stability issues I'm facing and hence I
>>> would like to force iwd onto the 5GHz band to see if the problems still
>>> occur. That proves to be difficult, of course, if iwd is picking the
>>> 2.5GHz band…
>>>
>>> Even though I do see that iwd probably has the better insight into band
>>> stability from a signal-strength point of view, any chance of
>>> overruling iwd's internal mechanisms here? (Or should I just crank up
>>> BandModifier5GHz by a couple of magnitudes?)
>>
>> All we have now is BandModifier5GHz which is multiplied by the computed
>> rank. The stock rank is based mainly on a data rate computation which is
>> theoretical, but uses capabilities and signal strength to estimate.
>>
>> 1000 is pretty high, so essentially your 2.4GHz BSS's would need to have a
>> rank 1000x larger than the 5Ghz ones. So either 5ghz is incredibly low
>> signal, doesn't support HT/VHT, or maybe the IEs are malformed so the data
>> rate isn't being computed correctly e.g. (defaulting to basic rates).
> 
> We had a request at the company to disable 2.4 GHz entirely as well, but I did
> not want to completely disable it as some customers may not even have 5 GHz
> infrastructure. My colleague Pedro drafted a patch which allows for the internal
> BSS ranking to be normalized according to a required bitrate, so that 5 GHz
> networks do not always out-compete 2.4 GHz networks. We found this worked well
> together with the BandModifier option.

Effectively yes this would work, though its not a guarantee to disable 
2.4 (although the option isn't named as such so its not deceiving anyone).

I personally don't take issue to adding such an option, but FWIW I'm 
currently working on a way to explicitly disable a band entirely. This 
is more complicated due to IWD's scanning logic but its better in that 
it prevents IWD from scanning on those bands as well as connecting.

Thanks,
James

> 
> I have asked him to send the patch to the list, so please take a look. Might be
> something of interest for upstream.
> 
> Kind regards,
> Alvin