CC3200MOD: Device Random Disconnects

Ran the same test against a NetGear R6200v2 router (V1.0.3.12_10.1.11 firmware) overnight and after nearly 20 hours have not seen the CC3100 drop off that network.

So this problem is router/firmware specific. We can live with that, but the long delay between actually dropping off the network and getting the notification is still an issue.

I have not yet. I am testing out an idea of what the problem could be. I will update this thread with the results - probably later this week.

The problem is with the CC3100, not with DD-WRT. DD-WRT is the means to easily expose this bug, but other routers may also cause the issue, but at a much lower rate and seemingly at random times.

Is the following report good enough to have TI R&D look into the issue described below, or do I need to submit this information somewhere else?

AES encryption has a feature for key renewal. The station attaches with the shared key and after that the station and access point encrypt messages with that key. After a while the best practice is to change to a new AP generated random key that is exchanged with the station using the current key in force to encrypt the interchange of the new key. On DD-WRT this is termed the "Key Renewal Interval". By default this is set to 3600 seconds (every hour), but can range from 1-99,999 seconds. Cisco routers can be configured with a higher interval time.

This is not just a DD-WRT (open source, who cares) issue - it will also be present against Cisco commercial routers, and others.

On DD-WRT it is possible to turn off the key renewal interval by setting it to zero. When I set it to 600 seconds the CC3100 fell off the network every ten minutes. When I turn the key renewal interval off the same set-up ran for 19+ hours with no issues. The only change was to disable the key renewal interval. This demonstrates to me that the CC3100 cannot handle the AES key renewal protocol.

I believe what is happening is that the CC3100 does not correctly interact with the AP during the key renewal and so the AP removes the device from its association table. The CC3100 does not know that it did not interact correctly and so is blindly unaware that it is not connected to the AP. The CC3100 then needs to send a packet (such as a keep-alive packet) and so transmits the packet on the correct frequency with the original shared key. The AP somehow decrypts enough of the received packet to recognize it comes from a device that is not in the association table and thus rejects it with the "class 3 packet from non-associated station" error response. The CC3100 then recognizes this error response and informs the controlling MCU that it has been disconnected because of this error. The MCU is able to react to the error and rejoin the network using the shared key and everything is fine until the next AES key renewal sequence fails.

The challenge is that the CC3100 may take up to one or two minutes to have reason to send a (keep-alive?) packet and thus the CC3100 may be completely unaware that it is off the network for that period of time.

We are following TI's reference designs forhow to configure the CC3100. There is no errata to state that the CC3100 cannot function correctly with AES key renewal.

Either there needs to be an updated reference design for configuring the CC3100 to correctly participate in AES key renewal, or there needs to be a firmware update to resolve the issue.

Colin,

When you performed the tests, what was the power policy set for the CC3100?

Can you perform the same test with the power policy set to Always On -

sl_WlanPolicySet(SL_POLICY_PM, SL_ALWAYS_ON_POLICY, NULL, 0);

Thanks,

Ben M

That change fixed the issue! Many thanks. Can you explain why this is working? I guess that the policy does not allow the CC3100 to go into sleep and so it is awake to react to the key renewal exchange.

With DD-WRT set up to renew the AES keys every 300 seconds...

• Without the always on policy (explicitly set to normal policy), 4 error disconnects in 25 minutes from boot/connection to the AP
• With the always on policy, zero disconnects in 25 minutes from boot/connection with the very same AP.

I'll take zero error disconnects over four error disconnects every day.

Is the policy persistent within the CC3100? I ask because I saw the improvement, then went back to the previous build that did not set the policy, expecting to see the problem, only I did not see it. I then changed the firmware to explicitly set normal or always_on in different builds to get the above results. Its almost as if the always on policy is persistent.

If it is persistent will the CC3100 intelligently not write the persistent setting to internal flash, or will it always write to the flash and hence we need to interrogate the policy before constantly settign it to always on?

Thanks for the clarification.

Note that DD-WRT is following the beacon / DTIM standard for indicating that a station has waiting packets when it awakes: https://www.dd-wrt.com/wiki/index.php/Advanced_wireless_settings#DTIM_Interval. This describes the way that stations are meant to wake to determine that there is incoming traffic (such as the AES key renewal sequence) and if there is waiting traffic to process it. Therefore I'm not sure why the CC3100 appears to have to be configured to be always on to exchange the new keys. My MacBook Pro and Samsung Android phone have no similar issues with the exact same router.

My router is running the very latest DD-WRT build - V3.0-r33215 Std (08/25/17)

It is current configured to renew keys every 300 seconds. The CC3100 fell off the network every 5 minutes with normal power setting. The CC3100 stayed on the network for over 12.5 hours with always on power setting before I took the test down.

Opinions:

In the US there is concern about ISPs being able to monitor and sell browsing history, etc. Numerous VPN services are advertising privacy solutions, directing consumers to purchase already configured routers running DD-WRT routers for those that just want a turn-key simple solution. If this trend continues then DD-WRT will become a more common router in the home, not just in the homes of network geeks

DD-WRT may become the "Linux of routers". It is noticeable that a number of router manufacturers are now actively embracing the project, supplying key information to the project for newly introduced routers so that the new router is quickly added to the list of supported routers. I would not be surprised if the next step for router manufacturers is to take the DD-WRT (Linux) Kernel and add their own web GUI on top, deciding which features to expose to their consumers, and which to hide from consumers using defaults. The wireless router market is a commodity market and any ability to reduce overhead and tap into latest standards implementations will reduce costs.

Sorry, this dropped off the radar as we worked around the issue by simply forcing the radio to always be on - our product always has to be powered to work and the extra juice needed for the radio is insignificant compared to the product's normal consumption. After months of testing with the radio always on we have not seen the issue repeat itself.

I will try to dust off the testing with the radio actively turning itself on and off (no work-around) and update this ticket. It may be a month as I am about to travel for 2 weeks.

Hi Colin,

Can you confirm the test setup used to recreate the issue:

* Device: CC3200

* Router Firmware: DD-WRT build - V3.0-r33215 Std (08/25/17)

* Router Model: TP-Link TL-WR810N

From this website, the TL-WR810N doesn't show up as a supported router: https://www.dd-wrt.com/site/support/router-database

Am I recalling the wrong router model or was there another that the issue appeared on that we can use as a reference?

Thanks,

Ben M