CC3100: Simplelink Auto Connect stops probing first profile in list

Hi William,

We are not familiar with such issue.
It looks like the profile gets deleted. Are you sure you don't call the sl_WlanProfileDel?
Please try the latest FW (2.11.0.1) and provide the network processor logs (see instructions in processors.wiki.ti.com/.../CC3100_&_CC3200_Capture_NWP_Logs).

Is it always the 1st profile? What happen if there is only one profile?
is it always the Enterprise?

How do you provision the device? assuming your application knows the ENT credentials, it can call the sl_WlanProfileAdd API once it is deleted (i.e. verify by reading the profile Info, using sl_WlanProfileGet) or once connection is not established within a certain time.

Br,
Kobi

Hi Kobi,
I can not get logs as the cc3100 is mounted without uart connections (spi only).
The code does not call profile delete.
With only one profile, it will eventually stop direct probing (broadcast only), but will connect if the target ssid responds.
Have not tried, non-enterprise.

On boot, or configuration change, we use profile delate all, then profile add for each. then set auto connect & don't change the profiles.

There are occasions where we set connection policy to manual & disconnect (to perform other processes while offline) then restart with a call to connect set to auto. We do not reload the profiles during this. Do we need to? I will try it.

Thanks,
Bill

Hi Bill,

Without getting the logs it will be very difficult for us to understand the issue and provide a fix, so we should focus on a work-around.
The profiles setting is persistent, so basically you don't need to access it (not even during boot) unless it is updated, but in your case you might need to check for profile existence (e.g. in boot) and add the profiles when needed.
If that won't help (as the profile exists even when the failure occurs), you may use other indications (e.g. continuous failure to reconnect) to refresh the profile list (delete all and add profiles manually).

Br,
Kobi

I modified the code to reload the profiles on any forced disconnect. It will take an overnight run to verify if it makes a difference. I will report how it goes.

I am surprised you have not seen this before. With the NWP 2.2.0.1, not sending directed probes, was seen with just 1 profile loaded.

Also, where can I get FW 2.11.0.1? 2.10.0.0 came with SDK 1.3?
Thanks

follow-up
test still running.
Found the 2.11.0.1 - release notes don't mention this issue. Will try it if test fails.

Hi Bill,

Are you deleting all the profile and add them again?
Depending on the frequency of the updates you should consider the flash memory wear out (each profile access update the profile file).
You may still want to read the content first before you decide to update.

Br,
Kobi

Hi Kobi,
Right now, just brute force delete & add.
If the problem goes away, it would point to the profile file (or possible buffering), and we can work on a better remediation strategy.
If the issue persists, we need to look elsewhere.
Thanks,
Bill

Same thing. took about an hour.
Will look deeper tomorrow.

Update:

Note: The test setup is such that the EAP-TLS network has a 5 minute session timeout.
This generates an SL_ERROR_DHCP_CLIENT_RENEW_FAILED event.
The CC3100, stays connected, but cant move data (bug?) so the firmware does a reconnect by:
Setting the connection policy to manual
calls disconnect
resets the connection policy to auto

There is also a valid WPA2 network setup the same (5 minute timeout) that it connects to instead of the targetr EAP-TLS

Ran an overnight test with
profile 0: WPA2 (dummy)
profile 1: WPA2 (real)
profile 3: EAP-TLS (real)
Connected to EAP-TLS at first
After ~ an hour stopped probing EAP-TLS, connected tp WPA
8.5 hours later it reconnected to EAP-TLS for 45 minutes : not sure if it was probing
reconnected to WPA network, 4 more hours, no prbes for EAP-TLS network
Stopped test.

New test
Added a 4th profile (WPA2 - dummy)
Re-ran test.
No EAP-TLS probes after 30 minuites, but the 3 WPA2 profiles are probed

Current test
Only EAP-TLS but using manual connection.
4 hours fine.

So it would appear that there is an issue with mixing enterprise & WPA2 profiles.
Do you know if this has been tested, through multiple reconnects?

Thanks

Hi Kobi,
I have been able to isolate the issue. that keeps the CC3100 in auto-connect from probing & connecting

After a disconnect, during the connection sequence

The cc3100 sends:
deauth
auth
auth accepted by AP
assoc
assoc rejected by AP with: Status code: Association denied due to reason outside the scope of this standard (0x000c)
retry
deauth
auth
auth accepted by AP
assoc
assoc rejected by AP with: Status code: Association denied due to reason outside the scope of this standard (0x000c)
The AP then sends:
Disassociate: Reason code: Unspecified reason (0x0001)

After that the CC3100 never probes or attempts connection to it again.
Even if I reload the profiles.

Same sequence can occur if a am doing the manual connection method. but in manual it always retries & eventually succeeds.

It appears there is some sort of persistent black-list in auto-connect.
If so, how do I clear it?

Thanks,
Bill

Hi Bill,

I'm not familiar with such black-listing logic.
What is the access point that you are using?
Can you provide an air sniffer log?
It will be very helpful if can get the NWP logs through P62.
processors.wiki.ti.com/.../CC3100_&_CC3200_Capture_NWP_Logs


Br,
Kobi

Hi Kobi,

It is a Cisco AP, unsure of model. It is supporting several SSIDs.

attached is a wireshark log it is already filtered on the CC3100's assigned mac.. it is not zipped, remove the.7z from the end.

look from the bottom up. & filter on the AP mac wlan.addr == dc:a5:f4:64:0d:82

I will see if I can wire up the uart on our board.

Thanks,

Bill

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/eap_2D00_tls_5F00_stops_5F00_probing_5F00_PS.pcapng.7z

It is pin 62 (TEST_62).

Br,
Kobi

installed latest service pack
WiFi Versions: CHIP 0x04000000 MAC 1.5.0.2 PHY 1.0.3.37 NWP 2.11.0.1 ROM 0x00003333 HOST 1.0.1.11
No difference
Will try to wire up debug out
Do I need to send a command to enable it?
Thanks,
Bill

Hi Bill,

Are you giving the ENT profile a higher priority once you add it (higher than the other profile)?
If not please try (priorities are 0-15, where 15 is the highest).
It seems that at some point, we got connected to the 2nd profile (probably because of temporary issue with the 1st one) and this connection is used afterward. The unicast probes are not sent as part as the connection procedure, but for neighboring networks tracking (for fast roaming in case of low SNR/RSSI).

Br,
Kobi

Hi Kobi,
I tried adjusting the priorities as the first test. I will try again.
Docs say enterprise takes priority regardless of priority setting.
Currently both at zero. Will set eap-tls to 7 and wpa to 0.
And report back.
Also looking to see if we can wire up a board for debug.
Thanks,
Bill

Adjusting priorities didn't make a difference.

Ran test with EAP, and a second non-existent profile, it reconnected fine over the weekend & the AP never kicked it off.

The issue is being seen with multiple APs/SSIDs/securities running off the same Cisco controller.
I am starting to think the controller &/or cc3100 are in a state believing they are either still connected, or connected to both SSIDs simultaneously ( missed de-auths & disassociates). The controller handles it by failing the association request. But the cc3100 sets (or doesn't clear) something that keeps it from ever trying to reconnect to the EAP profile.

We are going to attempt wiring up pin 52 (TEST_62) and try and get you some debug.
I will keep you posted.