CC3235SF: Facing frequent disconnection from from router, the following error is returned SL_WLAN_DISCONNECT_FRAME_FROM_NONAUTH_STA

Try to disable the use of PS poll (i.e. enable "no ps-poll").

See details in chapter 4.3.2.2 of the cc32xx NWP programmer's guide.

Br,

Kobi

Hi Kobi,

I have enabled No PS Poll on the device. This behavior is present with PS Poll disabled.

Regards,

Darpan

Can you provide an air sniffer log?

Hi,

It is difficult for my client to provide air sniffer logs of the network. Is there another easier mean by which we can capture details of the network. 

It will be very hard to find the issue without sniffer logs.

Such error is typically because we missed a disconnection message from the AP when we were sleeping in PS mode (so the AP think we are disconnected and we think we are still connected) and the main reason (that we are familiar with) for this is wrong handling of PS-Poll by the AP (so the AP is not sync on our sleep state).

So this supposed to be fixed when the PS-Poll mechanism is disabled. If this doesn't help - we must see logs.

are you using LSI? if yes, for how long? can you reduce the interval or disable LSI at all?

What is the frequency of the disconnection? what kind of traffic on the connection? (how much data and what is the interval between transmissions?)

Br,

Kobi

Hi Kobi,

Is there a user-friendly way of sniffing the WLAN packets, without needing special dongles?

Regards

There are some linux laptops (using Wireshark for example) that can use the internal wi-fi adapter for sniffing the air.

Not all the adapters supports this mode (promiscuous mode) so it is usually more simple to find a dedicated dongle that is supported by Wireshark.   

Hi Kobi,

I am not sure if it is possible to arrange for any of the device and sniff packets at the clients residence. Can we come up with some solution based on the CC3235SF itself?

We have updated the device with the following combinations and the result I observed follows it, we set the device with No PS Poll Enabled and the power management policy set to SL_WLAN_LOW_POWER_POLICY. With this combination it is observed that the device disconnects once every 5 minutes on an average. 

When the power management policy is changed to SL_WLAN_ALWAYS_ON_POLICY keeping the No PS Poll Enabled. There were no disconnections observed at all. Both the tests were observed over the same period. 

But the problem that arose due to the SL_WLAN_ALWAYS_ON_POLICY is that the power consumption increased which is not what we can afford. 

Since the Always On policy solves the problem can we narrow down the issue so as to maintain a low power policy along with the disconnections reduced?

The device it is observed on is the NETGEAR EX7300v2 — AC2200 Nighthawk X4 WiFi Mesh Extender. Here is the product link https://www.netgear.com/support/product/EX7300v2.aspx

Could you'll reproduce this issue??
And could you also provide a list of AP with which this issue does not occur? So as to recommend it to our clients??

Regards,

Darpan. 

We must have a sniffer. The router disconnects us when we are sleeping (in PS mode) - and we need to understand what leads to that.

I will check if we have this AP and if this can be reproduced.

Hi,

I do understand that the device is getting disconnected when it is asleep. But as per the implementation of No PS Poll we get a success when we enable No PS Poll.

Is it possible to still have PS Poll active after the process successfully completes?? Can setting the device's Power management to SL_WLAN_LOW_POWER_POLICY cause it to enable PS Poll or cause the disconnection?

What do you mean that you get success with "no ps poll"? I thought you mentioned it didn't make a difference.

The configuration is typically persistent (unless you disable persistency) so it should work when getting out of low power. 

I mean that when the api is called I get SUCCESS as a response without any error returned. This should be a valid confirmation for applying No PS Poll right?

I did mention that it made no difference and indeed it does not make any difference. The device shows the same behavior if No PS Poll is enabled or not.

I have disabled persistence in the device, hence I enable the power policies every time the device boots up.

I have a number of devices sold to end customers and they are reporting similar issues. I cannot compromise on the Low power policy and also cannot afford frequent disconnection. I need a solution immediately. 

I have provided you with all the information regarding the Clients environment even the router the person is connected with. Please try and reproduce this issue as I have to answer my end customers.

Why are you disabling the persistence?

Are you using auto or fast connect?

I think the PS-poll needs to be configured before the connection is established.

If the connection is established before, you may need to disconnect and re-connect to apply the PS-Poll disabling.

Please try to provide sniffer log of the issue.

We are not aware of similar issues (that are not solved with "no ps-poll").

Persistence is disabled to avoid flash writes. We set all the policies programmatically.

We also have auto/fast connect policy set. But to apply no ps-poll. we disable the auto/fast connect, disconnect the network and then apply no ps-poll.
And we have verified the setting has applied correctly by fetching no ps-poll from NWP using sl_WlanGet API.

Sniffer logs will be difficult as this is being reproduced at the end customer's premises.
I think it will be better you test the setup at your end. The router is not a legacy device it is mainstream equipment.

what SP are you using?

sp_4.8.0.8_3.7.0.1_3.1.0.26.bin

Please test with the latest (SP4.10) from SDK 5.10.

Br,

Kobi

Hi,

I have upgraded the devices with the service pack sp_4.10.0.1_3.7.0.1_3.1.0.26.bin and observed it over the weekend. It did not show any difference in the behavior. The number of disconnections are constant.

I have tried to revert the firmware on the remote devices back to the stable release, but the NWP does not downgrade to 4.8.0.8 back but it stays upgraded at 4.10.0.1. I need to downgrade it. Could you let me know how I can go about doing it?? [I need this solution on urgent bases]

Another thing I needed to clarify, while connecting to the AP we provide the BSSID of the AP to connect to it (api used is sl_WlanConnect). Can this be the cause of the behavior we are observing??

Regards,

Darpan

The SP contains a downgrade protection so you can't go back to 4.8 (unless you re-program the device and i believe restoring the factory image should also work). Do you see any new issue with the last SP? why do you need to revert?

Using BSSID in sl_WlanConnect should be ok.

There is probably some interoperability issue with the specific AP (again, we are only familiar with the PS-poll issue). We currently don't have it in our labs. We will try to get one but it will take some time.

I'm still not sure about your implementation. You previously mentioned you are using auto/fast connection but you are now talking about sl_WlanConnect. how do they cooperate?

Hi,

I have managed to capture the sniffer packets between the CC3235SF and the NETGEAR EX7300v2. Could you let me know an email address on which I can send the files?

In the logs it is observed that Router sends Deauth requests to Altro and then Altro disconnects and reconnect again. This happens frequently.

Please let me know where to send the files. I will attach device specific details on the email itself.

Regards,

Darpan

please use the friendship session (i just sent you a request) to send private messages.

br,

Kobi