On Sunday, September 19, 2021 6:53:45 PM CEST Kenneth Porter wrote: > --On Sunday, September 19, 2021 3:02 PM +0200 hw <hw at gc-24.de> wrote: > > None of this is working because the server isn't running a DHCPv6 server, > > and there seems to be no file in /var/lib/NetworkManager that would seem > > to be helpful. > > > > Isn't there a tool that creates the DUID and prints it? This can't be > > too difficult ... > > I found this thread that suggests that NetworkManager computes it every > time unless it's manually overridden: > > <https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/135> That might mean that I would need to extract the functions from the soruces of dhclient to make a program that prints DUID(s) for the machine you run it on. ... But that isn't so easy. Maybe I can find out how to create a DUID and write something in perl; it doesn't seem to be too complicated in the source. The comment is interesting: /* * The "best" default DUID, since we cannot predict any information * about the system (such as whether or not the hardware addresses are * integrated into the motherboard or similar), is the "LLT", link local * plus time, DUID. For real stateless "LL" is better. * * Once generated, this duid is stored into the state database, and * retained across restarts. * * For the time being, there is probably a different state database for * every daemon, so this winds up being a per-interface identifier...which * is not how it is intended. Upcoming rearchitecting the client should * address this "one daemon model." */ I don't understand what the point of a DUID is which is /not/ a per-interface identifier. When I assign addresses via DHCP, I don't want them to end up being assigned anywhere else than to the interface they need to be assigned to. What is intended with these DUIDs? > Based on that, nmtui-connect might do what you want. That seems to only allow to bring up or down a connection but doesn't display DUIDs?