Persistent WiFi setup from inside container


I am working to enable end user WiFi setup of a Raspberry Pi 3 device from a python gui running inside the container. The interface on the touchscreen allows the end user to enable/disable WiFi, choose SSID, and enter the password. The app is pyhon3 with wxPython for interface. I am currently able to use dbus to get wireless service info from connnman, so I can get the SSIDs along with their signal strength and type of authentication. I realize this will change to NetworkManager in the next resion os but still should be able to access with dbus. The next step is that once the user chooses what settings they want I will use dbus to have connman set it up, which from the docs does not look so bad.

My big question is that if the container changes host WiFi settings, will it get overwritten in the host os next time a new version is downloaded from resin? If not, then how does that work?

If it will get overwritten then the container would have to store the settings and would have to check/fix host WiFi setup every time the app starts up since I don’t think I have a way of knowing if a restart is due to new download or not.

- Shawn


Yes, I think that is the way.

You can save the credentials on a file, inside the /data folder, then, every time your app starts, get that file and set up the wireless network again.


Indeed as @diegosucaria mentions, there’s the /data partition that you can put things you want to be persistent over restarts / new versions of your application. resin-wifi-connect is a project that does couple of things similar to what you describe, so you might be able to get some inspiration from there. :bulb:

The checking/fixing on each application restart looks inevitable on first glance, though there might be some application logic which can help you distinguish different kind of restart and act accordingly. Doing the same check/fix on each start might be simpler, though.

If I understand correctly (but will need to test), using NetworkManager, the network settings are all stored, so can switch easier between known networks. (This is unlike Connman which supposed to be aware of only a single set of settings all the time, so need some more guidance)