CC3000 and WEP

I think the board supports it, but does the cc3000 module allow this. Example is WPA. I had a look through the Github repo for clues but nothing jumped out at me.

If you have control over the network, you should under no circumstances run a wifi network using WEP - you might as well not "secure" it at all; WEP was blown wide open years ago, and is now trivial to break into.

The CC3000 supports it, but the module does not:

In /libs/network/cc3000/jswrap_cc3000.c
we see this:

  char ap[32];
  char key[32];
  unsigned long security = WLAN_SEC_UNSEC;
  jsvGetString(vAP, ap, sizeof(ap));
  if (jsvIsString(vKey)) {
    security = WLAN_SEC_WPA2;
    jsvGetString(vKey, key, sizeof(key));
  }

So it looks like if any key is supplied, it uses WPA2.

I just changed that to WLAN_SEC_WEP and kicked off a build to test with
http://drazzy.com/espruino/espruino_1v68_espruino_1r3_CC3k_wep.bin

This does NOT have the bigram changes, and I didn't bother changing compiler flags, so you can't save() with it - but that should be enough to test whether that's all that's needed to make it work with WEP.

As @DrAzzy says - while the CC3000 supports WEP, Espruino just sets it up for WPA2.

It wouldn't be too difficult to add the option, but so far you're the only person to ask for it :)

There's no need to add WEP on my account. But is it just WPA2? I can't use WPA2 since it's a very old router I'm setting up - I've got WPA and WEP. I suspect looking at the code that @DrAzzy posted it is just later standard.

It's WPA2 only, there's also a WLAN_SEC_WPA defined right next to the other options - but per the code above, the module always chooses either unsecured or WPA2.

Ok thanks for confirming @DrAzzy.

@Gordon, one observation is that supporting other options can't hurt, with WPA2 as default. I know not everyone has a crappy old router they want to use, but not everyone can be on WPA2 either I imagine. I suspect I can upgrade my router firmware, but it's more 'friction' when perhaps it could just be an another argument in wlan.connect(

Just a thought, and thanks again for clearing up the current position both.

Yes, I've just added a bug for this.

At the time of implementation it was really just one less thing to write/test so it got left out. It shouldn't be a big deal to add.