Smart Config for consumer products? Alternatives?

Smart Config looks like magic the first time you see it - what it's doing seems impossible if you know a bit about encrypted wifi networks.

Back in October 2013, out of a sense of intellectual curiosity, I spent an unreasonable amount of time looking at decompiled Java and wireshark dumps working out what was going on.

In the end it turns out to be fairly simple - a clever trick, the core of which has been around for a while - Paul Edwin Charles Martin covered it in his 2007 thesis "Covert Channels in Secure Wireless Networks."

The best ideas are often simple - so would I use this one in a consumer device?

No!

It's insecure - you can make it secure but in doing so one loses most of the convenience the whole thing seemed to offer (a long unique AES key needs to be programmed into each device, included in the packaging shipped with the device and entered by the end user during setup).

And it's based on a "trick" rather than an established protocol, when it works then great but when it doesn't there's no easy way to diagnose what went wrong (and no one to complain to).

It's a broadcast only mechanism - the only point at which the device can respond to you is at the end if the whole setup process goes successfully.

The setup process can fail for various odd reasons (MIMO, MTU size etc.) where all the other networking hardware is operating correctly but just not in a way that Smart Config can handle.

So what would I use to communicate wifi credentials to a headless device?

Either a physical connection over USB or a wireless technology like BLE that allows for two way communication.

Smart Config sounds attractive in that the setup can be done with no extra hardware beyond the wifi module that the device is going to use anyway in its day-to-day activity.

Using USB or BLE requires additional hardware that's probably only ever going to be used once for the initial setup operation.

USB

First USB - it's a technology that even the most technophobic end user is familiar with and I suspect that, in the case of people who own their own wifi access point (AP), a larger percentage of people have a desktop or laptop with USB than necessarily have an Android or iOS smart phone (unless tablets really have replaced laptops to a greater extent than I imagine).

USB is an established bullet proof technology and the physical connection eliminates pretty much any security issues.

The downsides are that your devise design has to include a USB port and you have to package a USB cable with every device (even though 99% of consumers probably have spare cables knocking around).

BLE

For a wireless solution I think BLE probably provides the best option.

It's a cheap and relatively well established device-to-device communications technology that properly supports two way communication.

It's been included in Apple laptops since around mid-2011 and in many Windows based machines, the iPhone has had it since the 4S. Google originally bet on NFC and BLE has only been supported as standard in Android since 4.3, i.e. mid 2013 - however certain manufacturers have had their own support for longer, e.g. the Samsung Galaxy S range has had BLE support since the S III (released in May 2012).

So you can use many modern laptops or phones with BLE.

Note: laptops are in general out-of-bounds for Smart Config as it doesn't play well with the MIMO capabilities of modern laptop wifi chipsets.

So why would I use BLE that's only been around for a few years and not available in every device over Smart Config that works using wifi that every smart phone has supported since forever?

Because I'd rather know that my device will work with those devices that have BLE rather than offer a consumer device that can be setup with a wider range of phones but will mysteriously fail for a subset of those users for essentially undiagnosable reasons.

Let's look at setup - we've got three main devices:

• a phone running the setup app.
• the IoT device being setup.
• the wifi AP that we want the IoT device to connect to.

What are the most likely issues we'll see during the setup process? Probably:

• The phone can't see the IoT device.
• The IoT device can't see the wifi AP.
• The user provided wifi credentials are incorrect.
• The IoT device has connected but for some reason cannot see the public internet.

If using BLE all of these things can be sensibly reported (the first one by the phone, the others by the IoT device via the phone) and intelligently responded to, e.g. by moving the IoT device nearer to the wifi AP. Similarly if there is an issue that results in an unresolvable problem for many end users the IoT device can report all kinds of detailed diagnostics to the setup app that can be forwarded back to the manufacturer in order to track down the problem.

With Smart Config none of these issues can be distinguished. The whole Smart Config process could fail at the last step, where the CC3000 device tries to announce its successful connection by advertising its presence via (bastardized) DNS-SD, and the end user wouldn't see any difference between some kind of multicast failure at this point and a failure at the first-step (with the setup app being unable to even talk to the IoT device).

Only complete trial and error can resolve the source of any Smart Config failure - hardly ideal for a consumer device.

Smart Config tries, in the setup app, to pre-diagnose issues using the phone's own wifi hardware to check for things the CC3000 cannot handle, e.g. if the network is 802.11n only, operating in the 5GHz band, has too small an MTU size etc. This mitigates some of the issues, but ideally you still want the device to be able to report the issues it experiences.

And unlike Smart Config (without AES) the setup via BLE will be secure. To be honest I haven't looked into how security is achieved but as BLE is used in payment terminals (and end users are clearly not required to enter long AES like keys as part of the process) I presume they've got this covered in a consumer friendly manner.

Other CC3000 concerns

The CC3000 is one of the first really popular hobbyist wifi modules for use with Arduino etc. Adafruit and Sparkfun have produced shields and breakout boards for it.

The most active CC3000 community is based around the Spark Core from Spark Labs. The Spark.io forums show that a noticeable number of users, of presumably above average technical ability, have issues with the initial setup of their devices (quite apart from subsequent programming/development issues).

However many hobbyists, using boards like the Adafruit CC3000 breakout, simply hardcode their wifi credentials into e.g. their Arduino sketches which then configure the CC3000 directly rather than configuring it OTA and so use the CC3000 happily without ever using or running into issues with Smart Config.

If one uses the CC3000 without Smart Config are there still issues that concern me regarding its usage in consumer devices?

The main one would be confidence in the firmware.

The wifi chipset world is one in which companies like Broadcom, Atheros (now part of Qualcomm) and Intel dominate. TI is a much smaller player in comparison.

The CC3000 has been around since late 2011 - a while now - however rather than having settled into a phase of small fixes and minor improvements the release notes that accompany the CC3000 firmware updates still seem to regularly cover surprisingly major issues.

And some problems have required immense community effort to get resolved - e.g. the "cyan flash of death" seen in the Spark Core (the root cause of which was a TI issue). But hopefully projects like the Spark Core are finally driving TI to iron out the remaining major issues with the CC3000 and related chipsets.

On the TI forums it's nice that the actual engineers involved in the CC3000 project answer questions, however the quality of some of the answers are more disturbing than reassuring. In the case of the CC3000 firmware it seems clear that it's being developed by people primarily from a hardware background rather than some kind of expert hardware/software hybrid types and perhaps this explains somethings.

Hobbyist BLE development

So if you want to try out BLE where do you start?

First some terminology - Bluetooth Low Energy is often abbreviated as Bluetooth LE or BLE. In consumer marketing it's generally referred to as Bluetooth Smart and some people call it Bluetooth 4.0 even though it's only one part of the Bluetooth 4.0 specification.

Most hobbyist BLE breakout boards are based around chips from Bluegiga, e.g. the BLE112, or Nordic, e.g. the nRF8001.

Individual SMD BLE chips from Digikey etc. are extremely cheap, however BLE breakout boards from established names like Adafruit are relatively expensive, e.g. the nRF8001 breakout from Adafruit for $19.95.

There have been a number of one-off Kickstarter BLE projects and eBay is full of cheap Arduino friendly modules from random Chinese manufacturers.

There are numerous people offering BLE solutions for hobbyists, some of the things to look at include:

• RFduino - one of the few BLE/Arduino hybrids that's really available to purchase from sources like Mouser.
• BLEduino - one of the most talked about BLE/Arduino hybrids, much delayed but apparently now back on track.
• Many people have produced short run BLE boards etc., but some people's names come up again and again - e.g. Michael Kroll and Jeff Rowberg.
• The Arduino-BLE kit that has come out of the widely publicized Coin project.

But perhaps the most interesting crowd at the moment are RedBearLab - they clearly work very closely with people like Nordic and Arduino and produce a number or products including the new Blend Micro (a BLE/Arduino hybrid) and the BLE shield.

But perhaps most interesting is their BLE Mini as it, unlike most other BLE hobbyist products, has central role support. If you just want a simple device that can be controlled e.g. by your phone this isn't so important but if you want the device itself to play a more sophisticated role in a BLE setup then you probably need central role support. For an introduction to what central and peripheral roles and other terminology mean see one of these quick intros from Apple, Bluegiga (authored by Jeff Rowberg) or Android.

Note: there's quite a lot to BLE but many of the hobbyist solutions don't provide much more than a serial port style device-to-device wireless connection. If you look into BLE and decide that features like GATT sound interesting, e.g. you'd like to be able to record the heart rate information published by something like a Mio Alpha watch (that uses a standard GATT profile), then make sure to buy a device that actually supports that feature.

BLE/Wifi combos

Various people are pairing up BLE and wifi. E.g. the two are included in Intel's upcoming and much hyped (but no longer quite SD card sized) Edison.

Interestingly TI are also now producing a BLE/wifi combo module - the WL1835MOD (part of their WL18xx range).

The CC3000 can be used with very low end MCUs like the ATmega328 found in Arduinos, however TI clearly intend that the WL1835MOD be used with higher end processors like the Sitara AM3358 (based on the ARM Cortex-A8 core).

There's not much hobbyist support for the WL1835MOD - there is a cape, that was designed for the original BeagleBone but can now also be used with the BeagleBone Black, though the instructions aren't for the faint hearted (and, while the instructions mention Bluetooth once, they only actually go into testing out wifi).