0

Background

I will be house sitting for a friend this weekend, and she has texted me her WiFi SSID along with its password. Incidentally, her preemptively texting me the WiFi details got me thinking:

Instead of connecting to her network when I get there, I should just store the WiFi credentials on my laptop (with Ubuntu 19.10) and phone (with Android 10). That way, my laptop and phone can connect to her WiFi network automatically!

So, I did some research and saw that it might be possible (at least for my laptop; I think on Android, I would need root access), but there are still some remaining questions.

From my research, for Ubuntu 19.10, it seems that network credentials are stored in the following directory:

/etc/NetworkManager/system-connections

, and each file represents a credential. For example, one particular connection I have in that folder, etaoin-shrdlu, has the following contents:

$ sudo cat /etc/NetworkManager/system-connections/etaoin-shrdlu.nmconnection

[connection]
id=etaoin-shrdlu
uuid=515ab528-986b-4bb8-97fe-f744beaa0f2f
type=wifi
interface-name=wlp3s0
permissions=

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=etaoin-shrdlu

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=nice try hackers

[ipv4]
dns-search=
method=auto

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

[proxy]

This file seems relatively straightforward i.e. it looks like the only things I need to change are:

  • The file name.
  • The id value.
  • The uuid value (from reading online, this can be randomly generated).
  • The ssid value.
  • The psk value.

Presumably, the key management scheme to be used will be wpa-psk.

Additionally, I discovered that there is one more file that seems to partake in this ceremony:

/run/NetworkManager/devices/3

, which has the following configuration:

$ sudo cat /run/NetworkManager/devices/3

[device]
managed=true
connection-uuid=515ab528-986b-4bb8-97fe-f744beaa0f2f
route-metric-default-effective=600

, where the connection-uuid is the same uuid as the one specified in the credentials file.

Testing It Out

So, this is what I tried:

  1. Forget the network etaoin-shrdlu.
  2. Toggle airplane mode on.
  3. Create the following file /etc/NetworkManager/system-connections/etaoin-shrdlu.nmconnection (it was previously deleted after forgetting the network).
  4. Place into the file the same contents of the previous etaoin-shrdlu.nmconnection with the uuid changed to 630b5230-48cb-4929-9777-fa0f30399810.
  5. Modify the previous version of /run/NetworkManager/devices/3 to have a uuid of 630b5230-48cb-4929-9777-fa0f30399810.
  6. Toggle airplane mode off.
  7. Wait and hope that it worked...

And the result? It doesn't work.

Questions

  1. What am I getting wrong?
  2. What is the uuid key used for? Why is it OK for it to be randomly generated?
  3. Does the value for the psk key have any limitations for allowed characters?
  • even if you can alter those files, the documented method is through the nmcli command, not by editing the files. – A.B Nov 15 '19 at 23:35
  • Editing files of connection profiles is very much supported and intended and documented (well, somewhat :) ). However, nmcli might be more convenient. Note that only applies to profiles, not private files like /var/lib/NetworkManager/devices/. In practice, you may even edit those, if you know what you do and don't rely on stable API. – thaller Dec 7 '19 at 7:16
0

After you edit connection profiles on disk, you need to reload them with either nmcli connection reload or nmcli connection load [FILES...] (or via D-Bus API). Doing this has pretty much the same effect as changing profiles via D-Bus API, for example via nmcli connection modify ....

Note that if you edit NetworkManager.conf (or one of the conf.d snippets), you can reload via SIGHUP or systemctl reload NetworkManager.service. Some settings cannot be reloaded, and you need to restart the service instead. But usually restart is not necessary nor preferred.

Don't edit files in /var/lib, it likely does not what you want.

Anyway, so you modify/create the profile, and toggle airplane mode. Afterwards, autoconnect may happen. You are mostly good, because the profile you wrote has connection.autoconnect enabled. However, Wi-Fi profiles that were never successfully connected previously are not candidates for autoconnect. That means, you would have to manually activate the profile at least once, via nmcli connection up ....

You might also trick NetworkManager into thinking the profile was activated in the past. For that, set connection.timestamp to a positive value (a Unix timestamp in seconds). Note that the timestamps are usually maintained outside of the profile (because they get updated on each activation). Those are in /var/lib/NetworkManager/timestamps, but editing that file while NM is running may not work well.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.