Re: iwd picking worse network despite better one available

[James Prestwood <prestwoj@gmail.com>]

Hi Sven,

On 3/28/24 9:21 AM, Sven-Hendrik Haase wrote:
> On Thu, Mar 28, 2024, at 14:48, James Prestwood wrote:
>> Hi Sven,
>>
>> On 3/27/24 12:21 PM, Sven-Hendrik Haase wrote:
>>> On Wed, Mar 27, 2024, at 19:54, James Prestwood wrote:
>>>> Hi,
>>>>
>>>> On 3/27/24 11:36 AM, Sven-Hendrik Haase wrote:
>>>>> Hello,
>>>>>
>>>>> I've spent a good chunk of my evening looking into why iwd doesn't select the network I want it to select. I have a network "Home" with two APs. iwd seems to strongly prefer the AP that is further away and that has worse strength as measured by iwd.
>>>>>
>>>>>    From some testing, I believe it has to do with the AP rather than the wifi adapter. I tested a wifi adapter using mt7921e and one using iwlwifi and the result is the same in both cases. The APs are both pretty modern: The one iwd doesn't like is a FRITZ!Box 7590 AX while the one it likes is a FRITZ!Repeater 6000. From the log it seems that iwd is unable to perform a proper data rate estimation and then falls back to some default. At any rate, the rank would indicate that the estimated data rate plays an important role. If I use the developer mode to force roaming to the AP I want (named "better" in the log) then I'm able to use it perfectly well with a good data rate.
>>>>>
>>>>> As such I think this is a bug _somewhere_ but I'm not exactly sure where. I searched the configuration options but it seems it's not possible to turn off the data rate estimations for the ranking. I'd be perfectly happy to just go by signal strength. However, I suppose it would be better to actually fix the core problem in iwd.
>>>> IWD bases the ranking of BSS's heavily off the estimated data rate. If
>>>> that fails then as you see the rank is very low as it defaults back to
>>>> 802.11b rates. There are several IEs the AP sends which IWD parses, any
>>>> one of them could be either not included at all, or not be formatted
>>>> correctly, or an actual bug in the parsing code. Could you get an iwmon
>>>> capture of IWD scanning your APs so I could take a look and see exactly
>>>> why its failing? Then we can go from there.
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>> Hi James,
>>>
>>> You should have received a pcap file of an iwd restart in a separate email. I hope there's some usable data in there for you.
>>>
>>> Cheers,
>>> Sven
>> The issue is that the AP in question is not setting a bit correctly in
>> the HE capabilities element. As part of the HE PHY capabilities there is
>> a "Supported Channel Width Set" (Table 9-322b):
>>
>> — B2 indicates support for a 160 MHz channel width.
>> — B3 indicates support for a 160/80+80 MHz channel
>> width.
>>
>> And it then goes to say:
>>
>> B3 is set to 1 if supported. If B3 is 1, then B2 is set to 1.
>>
>> In your case B3=1 and B2=0. This is checked by IWD and fails. So this is
>> something the AP should fix. But at the same time this check actually
>> bypasses the VHT/HT/basic rates calculations which is why your only
>> getting 2mbps as the estimation. I just sent patches to the list fixing
>> this, so this should certainly help in your case, although the HE
>> capabilities will still fail to parse which means IWD will estimate
>> based on VHT instead.
>>
>> Thanks,
>>
>> James
>>
> Hey James,
>
> I just tested the patches and can confirm that they perform perfectly for me and I'm now getting the right AP selected along with incredible speeds so I'm happy. Looking forward to the next release of iwd!
>
> I also reported the problem in detail to AVM. Let's see whether they will actually get an engineer onboard to fix the fundamental problem.
Glad to hear it. The unfortunate thing is these bits come directly from 
the driver/hardware so the AP is probably just passing those as-is, 
which is what IWD does as well. They'll have to push on the hardware 
vendor to fix the bits. But in any case, glad the behavior is at least 
improved now.
>
> Cheers,
> Sven