Support for listing visible APs

[johnboiles]

Starting an issue to see if any thought has been put into an addition to Improv that would allow for listing APs that the device sees. This could make Improv more user friendly since the user could just pick their AP out of a list, then enter the password, instead of typing both their SSID and password.

You might wonder why not just do the scan on the host device, and use that list. Doing this on the Improv embedded device directly has a few benefits:

• Only APs visible to the embedded device would show up (filters out 5GHz only networks if your device is 2.4GHz only, restricts to only APs with enough signal strength to talk to the embedded device)
• Listing nearby APs isn't possible on iOS or WebBluetooth AFAIK (it's a privacy issue I think).

As mentioned I'm curious if anyone has put any thought into this. If not, I'll start looking into how I would add this either into Improv directly, or as a complement to Improv.

[jesserockz]

See RPC Command: Request scanned Wi-Fi networks on the website

[johnboiles]

Oh amazing sorry I missed that! Don't think that was there when I first set up Improv last fall or maybe I missed it. Thank you!

[johnboiles]

@jesserockz on closer inspection those docs are just for Improv over serial. Has there been any thinking on implementing this over BLE? Will be a little trickier because of the packet size, but perhaps you just send back one AP per packet, starting with the highest signal strength.

[johnboiles]

We're thinking about sending APs in the same way as Improv over serial, but just using a BLE serial library that reassembles the packets in a serial stream. Let me know if you have a better idea!

[BioSehnsucht]

Any update on implementing serial over BLE for this feature to be usable through BLE? I suppose is it is implemented in a device and client, you could do the entire process with it rather than the original BLE method.

[BioSehnsucht]

Some thoughts...this can be implemented a few ways. Personally I'm in favor of option C, but option A is not a bad path either. Option B seems like a weird middle ground that would required extra work for the same value as option C.

A) If we're already leaning towards implementing BLE serial, then the most straightforward solution is probably to add support for BLE serial as a virtual serial port connected to the existing Improv Serial code. Server side code would potentially need to support more than one serial port (if it doesn't already) but would otherwise mostly just pass traffic from BLE to the existing serial code, and back.

Of course we either need to pick a known set of UUIDs or make the client capable of discovering them from known potential list (as an example, see jakeler/ble-serial for the latter). If a known set of UUIDs, either pick custom ones or implement an existing set (i.e. Nordic). Going the ble-serial route of detecting it on the client side would potentially allow for various hardware-specific libraries to be used on the server side (as they might use different UUIDs depending on hardware), which might be helpful?

B) Use BLE serial, but only to allow passing larger response (and potentially request) packets through Improv BLE protocol. This might be implemented using the existing Improv Serial packet structure for replies but without all the commands accepted, or simply be raw strings being sent via BLE serial, or something in between. I'm not sure this makes a lot of sense vs either A above or C below, though.

C) Don't use BLE serial, but instead implement the SSID response via a new characteristic meant for reading out the list of known SSIDs (and their RSSI and needs auth flags), and a command to request the list.

I would think that, if we can send SSID plus password via BLE, we should be able to retrieve SSID plus RSSI and a flag of whether auth is required without any issues, per packet.

On the server side, when the request for scanned networks comes in, capture the current list of networks we've detected (it's assumed that scanning has been ongoing already, or will be done briefly if not before replying) into a buffer, then get the first item from the list and set it as the current value of the BLE characteristic. Every time a BLE read of this characteristic occurs, get the next item of the list and update the value with it. Rinse and repeat as needed until entire list is requested by the client. When we reach the end of the list, place an 'empty' reply as the value of the characteristic to signal end of list. Each reply would be formatted using the existing list-of-strings RPC result packet, but rather than trying to shove the entire list of SSIDs through at once, we're doing them one at a time, so less of an issue with packet size.

On the client side, when we want this information, we send the relevant command, then every time we are notified we read the next value until we reach end of list indication by the 'empty' value, at which point we have collected all the SSIDs.

[jesserockz]

Personally I like option C =)

[johnboiles]

We built a C++ host implementation. Let me look back at the protocol to see if it makes sense for us to contribute to the improv spec