Possible causes for frequent connection disconnection of 43455 with WiFi AP

[YaBh_4672321]

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.

[GauravS_31]

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.

[YaBh_4672321]

Hi,

Thank you for your response. I did reply to the email but I can not see the response here. I did get a mail with a response "Did it solve your problem? " but I can not see which solution is being pointed to neither can I see the mentioned comment here (a bug in community website?). Please re post the response.

The answer to your initial query is as given below:

The firmware version we are using is as follows:

WLAN Firmware    : wl0: May  2 2019 02:46:20 version 7.45.189 (r714228 CY) FWID 01-105ab14e

Currently getting Wireshark logs will be difficult as we are experiencing this issue at a remote site.

It might be important for you to know that on the same site, the device also has difficulty connecting to WiFi network i.e it takes multiple attempts (at times more than 10) for device to be able to successfully establish connection. The signal strength of the APs are varying but at any given time at-least 2 APs have good signal strength (< 40). The reason for join failure is error code 1006 (which translates to WWD_NOT_AUTHENTICATED" in join callback). We are unable to pinpoint why exactly is there difficulty in connected and then after connecting there are disconnections. The pattern of disconnection is something similar to device being stable for a few hours then suddenly it keeps disconnecting - connecting for few minutes then again enters a stable connection.

Any help will be appreciated.

Regards,

Yash

[GauravS_31]

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.

[YaBh_4672321]

Hi,

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.

Regards,

Yash

[GauravS_31]

You can also enable the macros given below to check if the WWD driver throws any error:

#define WPRINT_ENABLE_WWD_INFO
#define WPRINT_ENABLE_WWD_DEBUG
#define WPRINT_ENABLE_WWD_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.

[YaBh_4672321]

Hi Gaurav,

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

Regards,
Yash.