- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ GauravS_31, any update or thoughts on this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.