Wifi connection to configurable list of access points

[peterbarker]

We need a quick-to-implement way of defining a single WiFi client connection. This will be replaced by a more intelligent system later.

Proposal:

• use the existing port 8000 web server
  • take AP name / AP key
• directly invoke nmcli to create and/or modify the connection
  • it will have a consistent connection name (WiFiClient?)
• modify a daemon (MAVProxy? cherrypy?) to periodically check the list of APs seen (this requires the AP to beacon, obviously). If one is seen then bring up the client connection. It would have been nice if this was built in to NetworkManager, but...

Hopefully this will also permit having both the AP up and a client connection at the same time if you have multiple WiFi cards (or sufficiently funky WiFi chipset which can do both simultaneously).

[rmackay9]

After a discussion with @peterbarker, we are looking to allow the companion-computer to connect to a list of known wifi access points if it finds them but only using a secondary wifi modem - the main built in wifi modem should stay reserved for creating the existing wifi access point (called "ardupilot" by default).

The idea is that the user could connect to the local access-point and open a browser connect to the CC's the cherry-py webserver and then specify at least one access point for their home or office. The vehicle would connect to this when it finds it using the secondary wifi/modem.

Later on we will use this to upload data and log files to the internet.

[peterbarker]

These are some github repos that have initial work on supporting connecting via wifi to an existing access point:
https://github.com/peterbarker/companion/tree/wifi-client
https://github.com/peterbarker/companion/blob/wifi-client/Common/Ubuntu/wifi_client.sh

Nothing in that tree actually works; I was poking it periodically earlier this week.
I was imagining we would create a client connection as part creating the apsync image, and modifying stuff in the cherrypy server would invoke nmcli (or use the Python bindings for NetworkManager, possibly) to modify that connection.
A consistent name for additional WiFi interfaces would be required, I think (that's a bug in that script with the current plan, BTW, it mentions "wlan0", which is always going to be the AP).

[proficnc]

that would be really disappointing if the primary wifi cannot be used for this. to do swarming, the AP cannot be on the vehicle.

[peterbarker]

On Tue, 4 Apr 2017, proficnc wrote: that would be really disappointing if the primary wifi cannot be used for this. to do swarming, the AP cannot be on the vehicle.

This is a first cut. Perfect (and in this case, even reasonably flexible!) is the opposite of shipped.