We are facing a scenario where the Module at times keeps connecting and disconnecting to AP, we suspect that the module hops between available APs causing this behavior. Can this be reason for such behavior? What other possible causes be there for such frequent connection and disconnection (almost immediate disconnection after connection). It is observed that this kind of behavior happens consistently for sometime and then the network stabilizes and then after a while again this behavior is observed.
In a scenario where there are multiple APs with same SSID and password but different bands (2.4/5G) on what bases does the 43455 firmware decide which AP to connect to from all the possible APs?
Any any will be appreciated.
Please let us know the 43455 firmware version as well as the driver. Perhaps the wireshark airlogs could give a better picture of the disconnection behaviour. If there are multiple APs with same SSIDs, the AP with stronger RSSI would be preferred.
You can try testing with latest 43455 firmware version 7.45.221 available in the FMAC release Cypress Linux WiFi Driver Release (FMAC) [2020-09-... - Cypress Developer Community
If the issue still persists, you can capture the link event code in WICED by enabling WPRINT_ENABLE_NETWORK_DEBUG in wiced_defaults.h and share the link event output.
Apart from WPRINT_ENABLE_NETWORK_DEBUG and other macros macro under wwd_debug.h (we dont have wiced_defaults.h file in our project), do we need to enable any other type of logs before passing them on to you? I am attaching the wwd_debug.h file here for your reference.
The reason I am asking is as the setup is remote, it might be difficult to run iterations of test.
You can also enable the macros given below to check if the WWD driver throws any error:
Besides this, you can add WLC_E_ROAM event to link_events in wifi.c. This will indicate whether a roam attempt occurred.
Regarding the error 1006, is the STA attempting to join an AP on a channel unsupported in the clm_blob? If so, please ensure that the AP channel is changed to a channel supported in the clm_blob file.
During disconnection, does the WLAN firmware crash/get locked up at any time? If yes, additional logging would be needed but i need to know whether it crashes.
We have collected logs from remote site on which the issue is seen. We managed to collect the logs for join failures.
Below is the information regarding the setup:
1. There are total of 12 APs with same name and password, 6 of 5GHz and 6 of 2.4GHz.
2. The APs form a mesh network.
3. As APs are located at varying distance, the signal of each AP is different.
Some of the observations are as follows:
1. Of the 12 APs from 6 dual band routers we are only able to scan only 7 of them - all 6 of 2.4GHz and ONLY one of 5GHz. We expect to see all 12 of them or at-least most of them.
2. As the end user did not have channel information available with them, we only have the channel information of the APs that were scanned, and it is as follows (1, 6, 11 for 2.4GHz and 40 for the one 5GHz that was found).
3. If we performed a join operation using the "wwd_wifi_join_specific" api, we see issue in only one AP (a 2.4GHz one) of the 7 found and all others connected seamlessly during the test performed. That failed AP had was on channel 11 with ~ -86dbm signal strength.
4. If we performed join operation with "wifi_join_network" api the issue was persistent. Attaching the logs for the same as "wifi_join_fail.log". Please note that along with the event number in wcd logs we have added the print for event status if it helps.
How do we know which AP (bssid) the device is trying to connect to of all those available when we use "wifi_join_network" API?
The WLAN firmware does not seem to lock up but you can see the logs and make sure for yourself. We arrived at this conclusion because we were still able to attempt join after the first join failure. Please correct us if we are wrong here.
Note: WLC_E_ROAM was not enabled in this test.
Please help us debug this issue