1.1.0 bug with wifi SSIDs

photon
Tags: #<Tag:0x00007fe2240a29f0>

#1

@mdma

Affects: P1 1.1.0
(i’ll test a photon shortly)

It appears this version introduces some bugs with WiFi SSID names.

  • “32TC” will NOT work. “test32TC” will work
  • “test 32TC” (note space) will NOT work.

We rolled out a firmware update this week. Some folk were on 0.6.3 (yes, old, but don’t change what isn’t broken) and some were on 1.0.1. Even folk moving from 1.0.1 have reported the new issues. It’s something I honestly just didn’t think needed testing.

You can easily replicate it:

## Reset wifi creds via button. Set your guest network SSID to 32TC

Marks-2017MBP:sdbserverprocessing markterrill$ particle serial wifi
? Should I scan for nearby Wi-Fi networks? Yes
? Select the Wi-Fi network with which you wish to connect your device: [rescan networks]
? Select the Wi-Fi network with which you wish to connect your device: 32TC
? Should I try to auto-detect the wireless security type? No

[this is where it just hangs]

## Reset wifi creds via button. Set your guest network SSID to test32TC

Marks-2017MBP:sdbserverprocessing markterrill$ particle serial wifi
? Should I scan for nearby Wi-Fi networks? Yes
? Select the Wi-Fi network with which you wish to connect your device: test32TC
? Should I try to auto-detect the wireless security type? Yes
> Detected WPA2(PSK/AES/AES) security
? Wi-Fi Password smartfireWIFI
Done! Your device should now restart.

Success!

## Reset wifi creds via button. Set your guest network SSID to "test 32TC" to test spaces

? Should I scan for nearby Wi-Fi networks? Yes
? Select the Wi-Fi network with which you wish to connect your device: [rescan networks]
? Select the Wi-Fi network with which you wish to connect your device: test32 TC
? Should I try to auto-detect the wireless security type? Yes
> Detected WPA2(PSK/AES/AES) security

[hangs again]

We send wifi creds over a third party bluetooth chip, so we don’t scan from the device itself, we set it via WiFi.setCredentials. So on customer devices the issue manifests itself with green blinking, rapid green blinking, green blinking, rapid green blinking and then our connect timeout of 1 minute kicking in and going to dark blue blinking / setup mode. For the last 2 days I’ve just been asking folk what their network name was, the first reported issue was an old customer who had spaces in his wifi network name. Second one was 32TC, presumably the chip not liking a variable/string starting with a number.


#2

Anyone going to answer? Or are you too busy turning off api domain names?


#3

That kind of sarcasm won’t help your cause IMO.


#4

Hi @mterrill,

Sorry about the delay here, the firmware team doesn’t always get a chance to read the forums, filing an issue ( https://github.com/particle-iot/device-os/issues ) is often a quick way to get a response as well, since the firmware team sees those more frequently. (The Particle offices were also closed July 3rd - 7th, and lots of folks were on vacation).

Thank you for posting this bug! Did you get a chance to try it on a photon, or with a newer version of system firmware? The more observed behavior we can include in the bug filing will help us identify the issue.

Thanks,
David


#5

@mterrill - did you resolve this issue? As David mentioned, it’s worth trying with the latest DeviceOS firmware and if the issue still persists, please file an issue on the device-os github repo.

Many Thanks!


#6

1.4.0 works with spaces.

It’d be nice if:

  • There was some PVT on SSIDs etc.
  • Factory chips didn’t still ship with 0.5.x

#7

PVT = Product Validation Test? I understand that increased regression test coverage has been a focus for the development teams so hopefully these sort of issues will be caught before release.

Your SSID name starting with a number got me searching - I haven’t seen any before - I found this:

https://www.tech21century.com/best-wifi-ssid-names/


#8

Yeah, product validation test. Common term used across IT disciplines to check that what you’re selling or serving is actually still working. Sometimes it’s hard to do it before launch due to lack of a 1:1 test environment, sometimes the developer of X component just does unit tests that pass their view of the world, sometimes what you tested fine in preprod simply didn’t translate in the real world. Either way, PVT is generally more stringent than development test cases and a lot more common in real life than the idealistic world where everything is caught pre-release.