FMAC v5.4.18 slowpath mesg and not connecting to stronger APs via bgscan -50

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
EdTy_2191711
Level 2
Level 2
10 sign-ins 10 replies posted 5 sign-ins

Hello,

We are experiencing a very similar issue to the unanswered ticket below:

Problem With Disconnecting 1DX when signal stregths is weak

Build is the latest Linux kernel supported by murata GitHub - murata-wireless/meta-murata-wireless  (branch imx-sumo-manda). The board is a custom board based of the imx7dsabresd SDK with 1DX module ( Linux version 4.14.98 ).

We've updated to the latest FMAC version: v5.4.18-2020_0402 as proposed by the above ticket.

All wpa_supplicant family of tools are version 2.9

There are no issues connecting to an AP, but in a mesh system with all APs having the same SSID and passphrase we also get the brcmfmac "warn_slowpath_null" dmesg message unwind. Monitoring the signal strength and the "connected to AP MAC" of the APs within the mesh, the wpa_supplicant setting bgscan="simple:30:-50:300"  has no effect. Between two AP's monitoring which one we're connect to the connection does not jump when the non-connected AP get stronger than -50. The change is only when the current connection goes out of range.

 

These maybe two separate issues - warn_slowpath, not disconnecting at -50 but there is certainly a relationship.

Exactly the same issues are seen on the earlier murata krogoth branch ( 4.9.88 ) using the very latest backport FMAC driver. The branch is still used in current production units so just as important.

Thanks.

0 Likes
1 Solution

Thanks, after much trial and effort things may have settled down. Googling bgscan forums it appears the changing of AP is not just based on signal strength but also data rates etc before it makes a decision. This driver appears to agree.

View solution in original post

0 Likes
5 Replies
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

Did you change the WLAN firmware to the one used in the latest FMAC release? The latest version is 7.45.98.97. It contains the necessary fixes for the referenced forum thread.

0 Likes

Yes I just checked it on the actual board using a hex tool in case Yocto failed to pull it in:

Version: 7.45.98.97 (r724416 CY) CRC: 588b07d3 Date: Sun 2020-02-16 22:41:02 PST Ucode Ver: 1043.2137zFWID 01-bf41ed64

I don't see the slow_path issue as much as the person in the link, my main issue is not jumping to a stronger AP in a mesh network something our customers are getting frustrated with - bgscan="simple:30:-50:300"

Is there some debug I can set to send some logs?

0 Likes
EdTy_2191711
Level 2
Level 2
10 sign-ins 10 replies posted 5 sign-ins

@ GauravS_31, any update or thoughts on this?

0 Likes

You can refer to this post FMAC Debugging to obtain driver level as well as FW level logs. This will help us get a better picture.

Thanks, after much trial and effort things may have settled down. Googling bgscan forums it appears the changing of AP is not just based on signal strength but also data rates etc before it makes a decision. This driver appears to agree.

0 Likes