NetworkManager (via dbus) does not store password despite psk-flags=0

Project help
1

I’m using the dbus interface to create a new wifi network connection, however the password is not being written to disk at /etc/NetworkManager/system-connections/ID_wifi.nmconnection.

The config lacks the psk= entry:

cat /etc/NetworkManager/system-connections/ID_wifi.nmconnection
[connection]
id=ID_wifi
uuid=f0430ef1-953a-439d-91f8-0053691d7566
type=wifi
autoconnect-priority=101
permissions=

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=SOME_SSID

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
...

For comparison a connection created through the balena dashboard does have the psk= entry

cat /etc/NetworkManager/system-connections/somewifi.nmconnection  
[connection]
id=somewifi
uuid=ba9630cd-e809-461a-956b-cb41e4e4354e
type=wifi
permissions=

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=somewifi

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=somewifipw8

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

[proxy]

I tried configuring using the psk-flags=0 entry in the [wifi-security] section, but that seems to not work.

Does anyone have experience with this?

2

Hi,

Just to clarify a few things.

  1. Where are you looking for the system connection; host or container?
  2. How have you set up your container; specifically the DBus part?
  3. Do you see the same thing when using nmcli to change the password?
3

Hi @TJvV, thanks for your help and apologies for the late reply, I was on holiday.

  1. On the host.
  2. docker-compose.yml snippet for the relevant service:
  switch:
    image:  ghcr.io/...
    labels:
      io.balena.features.dbus: '1'
    restart: "unless-stopped"
    command: ['./entry.sh']

The entry.sh script contains

#!/bin/sh
export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
binary_to_run
  1. When I use nmcli to create a new connection on the host - the password is stored to disk as expected

One thing to point out: I first create an unsaved connection which I then save as soon as the network connectivity has been confirmed.

Running the exact same code on my machine locally works perfectly fine. The balena device runs NetworkManager 1.28.0, where locally I run 1.22.10

4

Hi,

Can you also share the code you use for configuring the connection through DBus?
It seems unlikely to me that the behavior would change between the nmcli call (which also uses DBus) and your own.

5

@TJvV I agree that it is strange.

First of all, I can now reproduce this on my local machine, so it is not a balena issue.

The code is in rust and does a few more things. I can share part of it, but I believe the problem lies somewhere within NetworkManager or I misunderstood some NM behaviour…

However, I believe I found a solution, but some context first:

We are managing two network connections simultaneously and are doing a one off state transition from State A:

  1. No wifi connection
  2. A ethernet connection in auto ipv4 mode, but that might not be plugged in

to State B

  1. Wifi connection provides internet (ipv4 auto mode)
  2. Ethernet with static IP and a static route (connecting to a second device)

We start in state A, create a checkpoint and apply the change using unsaved connections so that a loss of power would put us back in state A. As soon as we confirm connectivity in state B we save the connections to disk and delete the checkpoint.

For the save we simply use the save dbus call with the path to the two connections.

What I observed was that if I had the Ethernet connections (2) ipv4 config in manual mode as per my requirement for State B, the WIFI password did not get saved in the /etc/NetworkManager/system-connections/somewifi.nmconnection file.

But, if I set the Ethernet connections ipv4config to auto mode, the WIFI password was stored to disk.

In both cases I printed the wifi network connection settings prior to sending it on the dbus and the password / psk field was there, as expected. In both cases the wifi does connect as well, so it certainly is being understood by dbus and networkmanager.

My fix/workaround is to update (instead of save) the connections after the connectivity is confirmed, which also performs a write to disk. Now the WIFI password is set in both the Ethernets manual and auto mode cases.

Certainly strange behaviour. I’ll report back here if the status changes.