Nmcli from app container edit connection and persist?

Product support
1

Hello,
I would like to know how to save my edited connection using nmcli from the app container.

I use my wlan0 (static hotspot running flask) to setup wlan1 (internet).
It successfully changes the connection and I get the devices goes online.
If I reboot the device the device has still got the old values inside /resin-boot/system-connections/resin-wifi-01. I know there is a persist or save flag, but it should be true by default. Does it have something to do with permissions?
Thank you

@app.route('/wifi_save', methods=['POST'])
def wifi_save():
    # edit using nmcli
    ssid = request.form['ssid']
    password = request.form['password']
    os.system("./nmcli connection modify resin-wifi-01 wifi.ssid "+ssid+" wifi-sec.psk "+password+")
    os.system("./nmcli connection down resin-wifi-01")
    os.system("./nmcli connection up resin-wifi-01")
    return "Saved: SSID =>"+ssid+" password =>"+password
13

Please take a look at the bottom of Changing the Network at Runtime section in our documentation where there is an explanation of how the different NetworkManager connection settings folders relate to one another.

You may also take a look at our WiFi Connect project for an easy way to setup a wireless network.

1 Like
18

Hello,
thank you very much. I know now why it does not persist. First of all, nmcli modify is only temporary. If I add a connection using nmcli dbus the problem is there is no two way binding between appcontainer <-> host OS (/resin-boot/system-connections). I have read at boot, the files are getting transfered to /mnt/state/root-overlay/etc/NetworkManager/system-connections. So how does resin-wifi-connect persist the connections? Does it store the connection file in /data (persistent volume) and copies it at start into /mnt/state.... I have read it stores a .json persistent?

The reason I cannot only use resin-wifi-connect is that my customer, if he wants to reset the wifi password, cannot get out of the loop--clear true.

19

Edit: the information in this post is partially incorrect. See the following answer for further clarification.

At boot the connection profiles are copied to /mnt/state/root-overlay/etc/NetworkManager/system-connections. That is a persistent location however, which may contain other connection profiles. If a connection profile with the same name exist there, it will not be overwritten during the boot time copy.

This is the location where WiFi Connect stores the connection profiles as well. It uses the NetworkManager API for this in a similar way nmcli interacts with the NetworkManager daemon.

That is to say nmcli modify should not be temporary. If for some reason nmcli modify does persist the changes, can you please let me know the OS version and board type you are experiencing such a problem, so that I can try to reproduce?

Also you may check the just released version of WiFi Connect: 4.0.0. It no longer has the --clear flag available and allows supporting multiple connection profiles. For a detailed description of the changes please take a look here: https://github.com/resin-io/resin-wifi-connect/pull/157

1 Like
20

@majorz and @rquant, at boot, the files in /mnt/boot/system-connections WILL get copied over the files in /mnt/state/root-overlay/etc/NetworkManager/system-connections, so if you modify resin-wifi-01 connection at runtime via NMCLI or the dbus interface and then later reboot the system, the connection will get overwritten with the old connection file in /mnt/boot/system-connection. Which makes it look like things are not persistent.

My suggestion would be to rather create a new connection file instead of modifying the default resin-wifi-01 connection. It also might be a good idea to set the autoconnect-priority on this new connection to a higher value than the default one, so that one gets used, or deactivate the default connection.

1 Like
21

I have read this section so many times and never came to my mind that removing != replacing (without removing any files from the destination). Thanks for the clarification Shaun!