Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The ti cc3000 wifi chip has a special smart config mode, this is to allow the initial configuration of the wifi access details.

The cc3000 wiki page gives some details on how the process works,

  1. The chip enters a smart config "listen" mode
  2. Application on smart phone sends a "UDP" packet with access point settings
  3. The chip captures this data and configures itself

I am aware of packet capture and wifi sniffing, but how does the chip "decrypt" the raw packet to get any info out of it ? I use wpa2-personal with AES on my router.

share|improve this question
Thanks for starting a conversation about this on the TI forums - e2e.ti.com/support/low_power_rf/f/851/p/253463/983616.aspx - I have asked follow up questions there. And not been very happy with the answers. It seems the CC3000 relies on security through obscurity if one is not using it with an AES key. Note that they claim that the processors.wiki.ti.com/index.php/… page pointed to by @GregSadetsky is outdated but do not go into what supersedes it. – George Hawkins Aug 4 '13 at 13:57

As @Colin mentions the scheme that TI now use to communicate a network SSID and keyphrase from a setup application to a CC3000 enabled device is called Smart Config.

Smart Config has to communicate information (the network SSID and keyphrase) from a secure wifi network to a CC3000 enabled device that is not yet able to decrypt the traffic on that network.

Initially the CC3000 is not connected to the network (but can monitor the traffic), so the Smart Config application cannot send its information directly to the device. Instead it sends UDP packets to another existing machine on the network - the wifi access point (AP). That the AP isn't interested in receiving them is irrelevant, it's just important that the packets be visible on the network.

While the CC3000 can monitor the traffic it can't decrypt it, it can't even tell for certain that a given encrypted packet contains UDP data. So how can it pick out the UDP packets or do anything useful with them?

Basically Smart Config encodes its information not in the content of the packets it is sending but in their length. Wifi encryption affects the length of packets, but in a consistent way, i.e. it adds L additional bytes to the size of every packet, where L is a constant.

The Smart Config application encodes the SSID and keyphrase into the packet lengths of a sequence of UDP packets. The CC3000 can see the encrypted packets and their sizes.

In many environments the CC3000 will be able to see traffic from multiple nearby networks so how can it spot the relevant traffic? Even after encryption one can still see the MAC addresses of the source and destination of a packet so one can group traffic this way. In addition to the primary information that Smart Config is trying to send it also sends out regularly repeating patterns of packet lengths, so the CC3000 groups the traffic as described and then looks out for such patterns, when it finds them in the traffic of a given source and destination pair it then focuses in to recover the primary information.

There's obviously more too it than that, e.g. even once the CC3000 has found the source and destination pair, that correspond to the AP and the machine running the Smart Config application, how does it filter the Smart Config packets from other unrelated traffic going between the AP and the machine? I've written this all up in a series of blog posts.

The most technically detailed one covers the heart of Smart Config - how it encodes the SSID and keyphrase and transmits them such that a CC3000 can pick them up:


Then I have a post that's less technical, more an opinion piece about why you should always use an AES key with Smart Config:


There is a technical bit in the middle that does describe briefly how you'd configure a cipher in Java with the necessary AES transformation needed to work as the CC3000 expects.

And finally the proof of the pudding - I wrote an application to emulate the Smart Config related behavior of the CC3000, i.e. it can recover the SSID and keyphrase transmitted by any Smart Config application without needing to be able to decrypt the relevant network traffic. You can find where to download the source and all the details here:


This should enable one to test the behavior of any Smart Config application one writes, i.e. one can see what a CC3000 would be able to reconstruct from the data transmitted by the application.

I also have a few more Smart Config / CC3000 related posts:


For some background information it can also be interesting to read through these threads on the TI forum relevant to the CC3000.

First one covering Smart Config itself:


And one on mDNS, the mechanism by which a Smart Config application detects that a CC3000 enabled device has joined the network:


In both threads some initial messages may not seem so relevant but there's some interesting information mixed in too. But there's also a lot of inaccurate information as well so don't assume all of it is correct, even information from TI employees or from me (I learned a lot eventually but started with some incorrect assumptions/beliefs).

Patents have been mentioned a few times, however I can't find any evidence that there are patents pending or granted on this technology.

share|improve this answer
See this answer, with related comments, to a question I asked on the Cryto stack exchange - it seems to show clear prior art for the packet length encoding idea at the heart of Smart Config. This should be relevant to whether any part of the process can be patented. – George Hawkins Oct 21 '13 at 23:09

NB As noted in the comments to this answer, and in the other answers, the answer below does not reflect the current procedure. Leaving this for the historical record.

It seems like the CC3000 is actually listening (in "promiscuous mode") on all wifi channels for an AP probe request, the probed (and fake) AP's SSID containing the information that the CC3000 requires to configures itself to connect to the "true" AP through which it will connect to the Internet.

After searching a bit, I found this description of the device's first time configuration which should make it clear:


Most interesting bit:

A device such as a mobile phone or tablet used for performing a first time Configuration needs to be configured to connect to an AP with a specially crafted SSID. This SSID includes the name of the SSID to which we want the CC3000 to connect, as well as information about security options such as security type and key.

share|improve this answer
Minor point - the CC3000 always used monitor mode rather than promiscuous mode. The First Time Configuration approach described in this answer, and on the linked-to TI page, has been superseded by one called Smart Config, which is covered in my answer. – George Hawkins Oct 16 '13 at 20:52
This answer does not relate to the SmartConfig approach but to the old procedure which is no longer used by current devices. – Johannes Overmann Feb 10 at 9:43

Look at this page for information.

The AP isn't involved in this process. The CC3000 is listening to the UDP packets from the mobile phone or other device. This communication is encrypted with AES, both devices having it. The mobile phone sends information about the router WPA2 key in these packets. The CC3000 knows the AES key used by the mobile phone, decodes the data and connects to thr router.

share|improve this answer
hi, From the page " the device used to configure (smartphone, tablet, or PC) stays connected to the user’s home network during the configuration process (as opposed to other methods that require disconnection)." Since I do not disconnect my existing connection any packet sent will be encrypted to wpa2, can u explain this further? – srinathhs Mar 21 '13 at 6:08
@srinathhs: I can't explain the discrepancy. Post on the E2E forum, they'll answer. – Gustavo Litovsky Mar 21 '13 at 6:14

@Greg Sadetsky's answer (describing "First Time Configuration") summarizes the basic process well. But it was revealed in the discussion on the TI forum that the CC3000 has changed the process by which this automatic configuration is performed. The new process is called "smartconfig" instead of First Time Configuration, and TI is apparently preparing a patent application for the technology. It seems to use a similar scheme where special Wi-Fi "probe" requests are sent, which cleverly encode the network credentials for the CC3000.

If you choose not to use an AES encryption key for the automatic configuration, the smartconfig algorithm uses an undocumented method to obfuscate the access point SSID and security key. This is not inherently secure since if anyone learns the obfuscation algorithm, through reverse engineering or other means, the wireless network security is jeopardized. Once the patent application is filed, it is public domain knowledge and you must use an AES encryption key with the CC3000 automatic configuration mode in order to be secure.

As of September 2013 the patent application has not been filed, based on review of 2012-2013 patent applications by Texas Instruments (Google Patent Search Link: Texas Instruments, sorted by most recent filing date).

TI has acknowledged the insecurity of the non-AES configuration mode and has said they will recommend using AES and make it the default in the future.

share|improve this answer
Hi Colin, you mention that as of September 2013, the patent has not been filed. Can you give a source for that? Thanks. – Alexandros Marinos Oct 8 '13 at 16:54
@Alexandros Marinos - I did an online patent search for patent applications filed by Texas Instruments, and I did not find any patents that seem related to connecting to a wireless LAN. I looked back through last year and didn't see anything related. – Colin D Bennett Oct 10 '13 at 15:27
Thanks for the response. In the US and UK, patents filed remain confidential for 18 months unfortunately. You can see this by doing a patent search on Google for patent applications filed in the last 18 months. So TI probably has filed for a patent on this, but the application isn't old enough to be published. Not being able to see this patent is really irritating as my company has also found a way to achieve the same thing but we're unsure if it infringes on TI's patent application. – Alexandros Marinos Oct 13 '13 at 23:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.