Hotspot registration fails and will no longer continue if wireless SSID contains non-ASCII characters

[crouchingtiger]

Describe the bug If your wireless SSID contains non-ASCII characters, you will be able to connect to your hotspot during initial setup, but registering a hotspot will fail eventually with a characteristic read error for UUID 7731de63-bc6a-4100-8ab1-89b2356b038b.

Subsequently, you will no longer be able to connect and complete your device setup at all, as you will no longer be able to see the list of scanned wireless networks / network selection view.

To Reproduce Steps to reproduce the behavior:

1. Create a wireless SSID with non-ASCII characters in it.
2. Add a new hotspot, and connect to the SSID you created.
3. You can skip location asserting and go straight to adding the hotspot.
4. Error for read of characteristic will appear.

Expected behavior If there is no change that will be made to the BLE interface, then the Helium app should warn users about this limitation in the app before they proceed and not allow them to continue. For those stuck "in-between" (set up with an invalid SSID and unable to understand the characteristic error), they should receive a more human-readable error if it's possible to read the saved state / saved SSID.

SSIDs as per the IEEE 802.11-2012 standard can contain any-non Latin characters, and should be UTF-8 encoded. No assumption should be made about their encoding. The above suggestion is a first-step, ideally any valid SSID should be permitted rather than being restricted to ASCII values.

Screenshots

Smartphone: Affects all devices and all app versions.

[cokes518]

Nice bug @crouchingtiger we'll definitely take a look at this. Ideally the right solution is to accept non-ASCII characters. We'll have to double check if the logic lives on the app, or the hotspot itself.

[Herr-Sepp]

Hi, i have also tryed to connect to a SSID with non-ASCII characters but I have observed a different behavior.

My SSID has a part with "@:M" but inside the App it is displayed als "@\:M" It seems that an escape character(\) is inserted into the SSID.

I can't get past step 2 of crouchingtiger. I already get an error there that the connection could not be established.

(If the modified SSID is used as it is displayed it can't work either).

[cokes518]

app is passing a string to the protobuf directly, so it's likely the encoding is being garbled downstream (in response to the original bug report)