public inbox for iwd@lists.linux.dev
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Denis Kenzior <denkenz@gmail.com>,
	Martin Petzold <martin.petzold@tavla.de>
Cc: "iwd@lists.linux.dev" <iwd@lists.linux.dev>
Subject: Re: IWD 1.27 with brcmfmac not working for roaming
Date: Tue, 15 Oct 2024 21:13:53 +0200	[thread overview]
Message-ID: <f496ad63-e2a6-46cb-b7d6-1a084523c7d9@broadcom.com> (raw)
In-Reply-To: <5efc11fc-9c21-44a0-b282-5d41bfb96a8c@gmail.com>

On 10/15/2024 5:17 PM, Denis Kenzior wrote:
> Hi Martin,
> 
>>
>> I think the regulatory domain issue is fixed. It seems that 99 is 
>> correct (because it is handled in firmware). We see far better signal 
>> and data rates at a site where we had problems. It seems the general 
>> setup is far better now for simple setups. We removed the 
>> configuration from device tree and then it may have used the 
>> configuration from brcmfmac4339-sdio.txt (device tree stuff was 
>> something the SOM vendor added for some reason).
> 
> Sounds like you're getting somewhere.

The firmware pretty much has its own regulatory rules or they are 
provided separately through the CLM blob. The fact that you can use any 
channels without the CLM blob indicates the firmware indeed has 
regulatory rules in place. If the SOM vendor did not provide one my 
guess is that the in-firmware rules are sufficient for this wifi module. 
In firmware the rules in use are determined by {country_code,revision} 
but the kernel only uses country_code. Hence brcmfmac supports 
configuration of a mapping between those. This may be done through the 
device tree (see brcm,ccode-map and brcm,ccode-map-trivial in [1]).

>>
>> However, I have now already seen at one of our testing sites, that it 
>> connected to the router instead of the repeater (which is far closer 
>> and has far far better signal: -67 vs. -29 dBm). It also did not 
>> switch to the repeater after
> 
> You may have to revise your expectations here.  Most implementations do 
> not trigger roaming unless signal quality reaches a certain threshold.  
> This includes many of the firmware roaming implementations I've seen.
> 
> For iwd this threshold is -70 dbm on 2.4G and -76 dbm on 5/6G by 
> default. Parking at the AP with good signal (-67 is good) is just fine 
> and I see nothing inherently wrong here.  And remember, the firmware is 
> responsible for roaming in the case of brcmfmac.
> 
> One may question why -67 AP was preferred over -29 one?  We'd need logs 
> to answer that question.  It could be the -29 one was simply not seen in 
> the scan results at the time of the initial scan / connection.

The roaming algorithm is not that intuitive. Roaming and rate selection 
are not based on signal strength alone. They may look at PER (packet 
error ratio) to decide. -29 dBm might actually be too strong. I always 
try to get between -40 and -60 dBm.

The nl80211 API actually offer the possibility to affect the BSS 
selection. The NL80211_CMD_CONNECT command can have the attribute 
NL80211_ATTR_BSS_SELECT for that [2]. When not provided the firmware 
will obviously use its default behavior whatever that is. Not sure if 
IWD or wpa_supplicant support this, but I am fairly sure brcmfmac 
supports it. However I do not know if it also applies to roaming.

>> several hours (both FritzBox - so consumer grade and we don't know the 
>> exact configuration). After a reboot, it connected to the repeater and 
>> until now it 
> 
> So that's... good?
> 
>> remains there. I will switch to more complex roaming environment, 
>> however, this is more sensitive because it is at a clients site. This 
>> first impression gave me not much confidence...
>>
>> What do you think about the idea to disable roaming in the firmware / 
>> driver? (if I understand Arend right, this is setting "roam_off" in 
>> brcmfmac4339-sdio.txt)
> 
> You can certainly give it a try.  It is not something we have tested 
> explicitly, but it should (mostly?) work.  However, note that trying to 
> make a FullMAC card roam from userspace in such a manner is inherently 
> limited.  iwd cannot utilize advanced roaming features such as FT with 
> such a setup (I can get into the technical details if you care).  Having 
> said that, roaming behavior is a frequent complaint for many fullmac 
> implementations.

AFAIK it is a module parameter.

>>
>> Will IWD smoothly take over the roaming? How can I check who is 
>> handling the roaming?
> 
> iwd looks at the NL80211_ATTR_ROAM_SUPPORT flag.  If such a flag is 
> reported by the wifi driver, iwd will let the firmware handle roaming.  
> Otherwise it will try to handle roaming itself with the (rather limited 
> in the case of fullmac) tools that it has access to.  Taking a peek at 
> the brcmfmac driver, looks like it is doing the right thing in setting/ 
> not setting this flag based on the "roam_off" parameter.

*phew* ;-)

Regards,
Arend

[1] 
https://elixir.bootlin.com/linux/v6.11.3/source/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
[2] 
https://elixir.bootlin.com/linux/v6.11.3/source/include/uapi/linux/nl80211.h#L2443

  reply	other threads:[~2024-10-15 19:13 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09  9:43 IWD 1.27 with brcmfmac not working for roaming Martin Petzold
2024-10-09 16:07 ` Denis Kenzior
2024-10-09 16:50   ` Arend Van Spriel
2024-10-09 17:54     ` Martin Petzold
2024-10-10  8:06     ` Martin Petzold
2024-10-12 11:06       ` Martin Petzold
2024-10-12 11:51         ` Arend van Spriel
2024-10-13 15:43           ` Martin Petzold
2024-10-30 19:19           ` Martin Petzold
2024-10-30 19:23             ` James Prestwood
2024-10-09 16:58   ` Arend Van Spriel
2024-10-10 13:20   ` Martin Petzold
2024-10-10 13:36     ` James Prestwood
2024-10-10 13:47       ` Martin Petzold
2024-10-10 13:55         ` James Prestwood
2024-10-11  8:35           ` Martin Petzold
2024-10-11 10:46             ` Martin Petzold
2024-10-12 10:59               ` Martin Petzold
2024-10-15 14:43   ` Martin Petzold
2024-10-15 15:17     ` Denis Kenzior
2024-10-15 19:13       ` Arend van Spriel [this message]
2024-10-16  2:04         ` Denis Kenzior
2024-10-16  8:32           ` Arend van Spriel
2024-10-17 10:58           ` Martin Petzold
2024-10-19 14:04             ` Martin Petzold
2024-10-19 14:41               ` Denis Kenzior
2024-10-21 13:34                 ` Martin Petzold
2024-10-21 14:40                   ` Arend Van Spriel
2024-10-21 14:53                     ` Martin Petzold
2024-10-21 15:23                     ` James Prestwood
2024-10-21 17:08                       ` Arend Van Spriel
2024-10-21 17:20                         ` Martin Petzold
2024-10-21 17:40                         ` Denis Kenzior
2024-10-21 18:26                           ` Arend van Spriel
2024-10-21 18:45                             ` Martin Petzold
2024-10-21 18:48                               ` Martin Petzold
2024-10-21 18:55                             ` Denis Kenzior
2024-10-21 19:08                               ` Jeremy Blum
2024-10-22 15:26                                 ` Denis Kenzior
2024-10-22 16:38                                   ` Jeremy Blum
2024-10-21 19:15                               ` Martin Petzold
2024-10-21 19:11                             ` James Prestwood
2024-10-21 20:23                             ` Martin Petzold
2024-10-22  6:08                               ` Arend Van Spriel
2024-10-21 22:01                             ` KeithG
2024-10-21 22:10                               ` Martin Petzold
2024-10-22 17:40                                 ` James Prestwood
2024-10-22 18:04                                   ` Martin Petzold
2024-10-22 18:21                                     ` Martin Petzold
2024-10-22 18:24                                     ` James Prestwood
2024-10-22 18:32                                       ` Martin Petzold
2024-10-22 18:44                                       ` Denis Kenzior
2024-10-22 18:47                                         ` Martin Petzold
2024-10-22 19:10                                           ` James Prestwood
2024-10-22 18:47                                         ` James Prestwood
2024-10-22 18:49                                           ` Martin Petzold
2024-10-22 18:52                                           ` Denis Kenzior
2024-10-23 12:02                             ` Martin Petzold
2024-10-23 12:13                               ` James Prestwood
2024-10-23 12:19                                 ` Martin Petzold
2024-10-23 13:22                                   ` James Prestwood
2024-10-23 13:34                                     ` Martin Petzold
2024-10-23 15:22                                     ` Martin Petzold
2024-10-23 15:27                                       ` Martin Petzold
2024-10-23 15:30                                         ` James Prestwood
2024-10-23 15:37                                           ` Martin Petzold
2024-10-23 15:28                                       ` James Prestwood
2024-10-23 15:11                               ` Arend Van Spriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f496ad63-e2a6-46cb-b7d6-1a084523c7d9@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=denkenz@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=martin.petzold@tavla.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox