esp32/modnetwork.c: Report SSID values as strings.

[StopHacking]

From WLAN, I would like to get reported SSID names as strings rather than byte arrays.
In the configuration, SSID names are passed via strings into the driver, and so reading SSID names
from the driver should return them as strings too.

[dpgeorge]

Sorry for the late response.

There are 2 independent changes here:

• Changing scan results to return str instead of bytes for the ssid. esp8266 returns bytes so that's how it should stay. It's really a bytes entity because it could contain non-ascii chars, and so converting to a str would be wrong.
• Allowing config('essid') to return the ssid of the AP that the device is connected to. As far as I see, this change is ok.

[nickzoic]

On Fri, May 19, 2017, at 11:04, Damien George wrote: Changing scan results to return str instead of bytes for the ssid. esp8266 returns bytes so that's how it should stay. It's really a bytes entity because it could contain non-ascii chars, and so converting to a str would be wrong.

Umm, yeah, I was going to point that out. The SSID is *generally* ASCII but you can't rely on that, it could be set to any sequence of bytes. If there's high-bit characters they *might* be a UTF-8 encoding so you could decode it into a string, but there's no guarantee it'll be valid or printable. It's kind of inconvenient for display purposes, but so it goes.

[nickzoic]

Re: config('essid') returning the APs SSID when in STA mode: I think this should be returned by status (along with RSSI etc). 'config' suits read/write parameters, I think.

Perhaps at the same time as we define AP status for #186 we can define a structure for STA status (and perhaps also for the Ethernet PHY #187)

[nickzoic]

Thanks for your PR and please do keep contributing but I'm going to close this particular PR because of the problems above.

A couple of thoughts on this work though:

1. The SSID can be set from a bytes() array, allowing it to be set from a string is a shorthand.

2 In 802.11-2012 6.3.11.2.2 there's an additional "SSID-Encoding" flag which indicates if the SSID encoding is "UNSPECIFED" or "UTF8", but there's no particular guarantee that it'll be valid or printable UTF-8 even if this flag is set so I don't know to what extent it is actually useful.

3. In practice, devices seem to have a stab at decoding the bytes as UTF-8 and just ignore anything which goes wrong: for example u'\U0001f4a9' displays as the pile-of-poo emoji and b'abc\0def'displays just as abcdef. Broken UTF-8 (eg: bytes([0xf0,0xf0])) displays as some other (chinese?) encoding on Android, and other characters on other systems

4. Perhaps it'd make sense to provide a Python helper function to "do the obvious thing" when displaying SSIDs but displaying arbitrary byte arrays as strings is a problem beyond just SSIDs

[dpgeorge]

Re: config('essid') returning the APs SSID when in STA mode: I think this should be returned by status (along with RSSI etc). 'config' suits read/write parameters

Yes, good point, config() is for configuring parameters of the wlan/eth/etc.

[nickzoic]

How do you feel about the dictionaries-and-lists format for status as I suggested in #186, eg for a connected WiFi station:``` { 'connected_ap': { 'essid': b'whatever', 'mac': b'\x74\xda\x01\xc0\xff\xee' }, 'rssi': '-22', 'rate': 54, 'quality': 0.83 } } ``` .... or something like that.

[dpgeorge]

How do you feel about the dictionaries-and-lists format for status as I suggested in #186, eg for a connected WiFi station

@nickzoic actually, if you read again the current network.rst docs it has an example for getting the STA RSSI: sta.config('rssi'). So that would be a way to cover that specific case. And generalisig that, config() could be used to retrieve other info about the connection, and for AP mode the list of connected clients. Note also the existence of "attrtuples" which are an efficient version of a namedtuple used to return info like this (see uPy's sys.implementation).