The UUID of a connection should never change after it's created. Most likely what's happening is that you're ending up creating multiple connections because (IIRC) eduroam is different enough in different places that NM doesn't recognize it as being the same network. (Eg, it uses different auth modes at different sites.)

The answer here might be "NM should special-case eduroam". It seems like there are always open bugs about authenticating to it...

(In reply to comment #1)
> The UUID of a connection should never change after it's created.

+1

> The answer here might be "NM should special-case eduroam". It seems like there
> are always open bugs about authenticating to it...

I'll try to ask some folks at an upcoming conference about their experience with eduroam and networkmanager and specifics of the eduroam networks. If any set of wifi networks should be special cased, it's definitely eduroam.

When a script creates a new connection specification file to /etc/NetworkManager/system-connections/, NetworkManager overwrites the UUID in the file. (If you test this, make sure you create the file with an ID/name NetworkManager has not seen since it started system-wide, i.e. since last bootup.)

Eduroam connections typically use WPA/WPA2 Enterprise security, tunnelled TLS or PEAP authentication, and MSCHAPv2 inner authentication. Since nmcli cannot supply the user password for these connections, automagic connections are only possible via user keyring.

Because NetworkManager sometimes changes the UUID when it first sees the connection file, I've had to use quite a complex workaround:

  1. Turn off WiFi (

When a script creates a new connection specification file to /etc/NetworkManager/system-connections/, NetworkManager overwrites the UUID in the file. (If you test this, make sure you create the file with an ID/name NetworkManager has not seen since it started system-wide, i.e. since last bootup.)

Eduroam connections typically use WPA/WPA2 Enterprise security, tunnelled TLS or PEAP authentication, and MSCHAPv2 inner authentication. Since nmcli cannot supply the user password for these connections, automagic connections are only possible via user keyring.

Because NetworkManager sometimes changes the UUID when it first sees the connection file, I've had to use quite a complex workaround for a *temporary* eduroam connection:

  1. Turn off WiFi
         nmcli wifi off

  2. Save connection file, with
         autoconnect=false
     so that NetworkManager does not try it immediately,
     before we have the keyring ready

  3. Wait until NetworkManager has the connection
     Loop until
         nmcli -t -f NAME,UUID
     lists the connection.
     The surprising thing is that at this point, the UUID
     is often different to the one saved to the file,
     especially if NetworkManager has not yet seen a connection
     with that ID (name) since last boot.

  4. Create the keyring entry
         "Network secret for NAME/802-1x/password"
         "xdg:schema" "org.freedesktop.NetworkManager.Connection"
         "setting-key" "password"
         "setting-name" "802-1x"
         "connection-uuid" (the new UUID as value)
     with the connection password as the secret

  5. Bring up the connection using
          nmcli wifi on
          nmcli con up uuid (the new UUID) --timeout 30

  6. Check for success/failure using
          nmcli -t -f WIFI,STATE

For me, it is not a problem that the secret remains in the keyring, as this is only used to verify the user and create a new user account.

I will use a variant of the above procedure to create the connection and add the connection password to the new account created for the user, although I'm sure you can see how convoluted the approach is. No wonder there are so many issues with Eduroam...

(In reply to comment #4)
>   3. Wait until NetworkManager has the connection
>      Loop until
>          nmcli -t -f NAME,UUID
>      lists the connection.
>      The surprising thing is that at this point, the UUID
>      is often different to the one saved to the file,

AFAICT, the only reason NM would assign its own UUID to the file would be if the ifcfg file didn't specify a UUID itself (which in this case probably actually means "specifies the UUID incorrectly such that ifcfg-rh doesn't notice that it's there").

Can you attach an example of one of the ifcfg files you're generating?

(Also, FTR, you can compute the UUID that NM is going to generate by running:

  python -c 'from gi.repository import NetworkManager; print NetworkManager.utils_uuid_generate_from_string("/etc/sysconfig/network-scripts/ifcfg-whatever")'

(In reply to comment #4)
> When a script creates a new connection specification file to
> /etc/NetworkManager/system-connections/

oops, I wrote the previous comment thinking you were using ifcfg-rh, but everything I said applies to the keyfile plugin too.

As Dan said, UUID doesn't (shouldn't) change. If you put an uuid=<uuid_value> to /etc/NetworkManager/system-connections/file, NetworkManager will use it. You can use uuidgen program or libnm utils function (mentioned in comment #5) or whatever to generate UUID.


(In reply to Jouko Orava from comment #4)
> 
>   3. Wait until NetworkManager has the connection
> 
NetworkManager doesn't monitor connection files by default any more (see monitor-connection-files in NetworkManager.conf). So you have to load the connection after you manually create (edit) the file.
$ sudo nmcli con load /etc/NetworkManager/system-connections/mywifi
or
$ sudo nmcli con reload

As for nmcli, it can't automatically create-and-connect to WPA Enterprise networks (nmcli device wifi connect). However you can create the connection via 'nmcli con add && nmcli con modify' or interactively with 'nmcli con edit'. That way UUID is generated by nmcli for you.

Example:
$ nmcli connection add type wifi ifname wlp3s0 con-name test-eduroam autoconnect no ssid eduroam                                                          
$ nmcli connection modify test-eduroam 802-1x.eap peap 802-1x.identity joeblack 802-1x.phase2-auth gtc wifi-sec.key-mgmt wpa-eap wifi-sec.proto "wpa rsn"

Also in NetworkManager 1.0, nmcli can ask for Wi-Fi passwords; just use --ask parameter, so that nmcli can interact with you.

$ nmcli -a con up my-eduroam-profile

Closing this as not a bug. It is as intended. UUIDs *are* the unique identifier, while IDs are not. If an UUID changes, you have an entirely different connection. If you don't want that, do not change the UUID.

A script that writes connection files directly, it must make sure that the UUID doesn't change.

As mentioned, both keyfile and ifcfg-rh support omitting the UUID from the configuration file. In this case a stable UUID is generated based on the filename -- which obviously changes if you rename the file.

After writing the file, you want to issue `nmcli load` or `nmcli reload` -- unless you configured main.monitor-connection-files=yes.



If there is the issue that you have *different* connections that all require the same password, this would be a different feature request. Currently such a configuration is not supported.



Please feel free to reopen if there is more to discuss. Thank you