> Steps to Reproduce:
> 1. nmcli con add type dummy con-name dummy0 ifname '*'
> 2. nmcli con up id dummy0 ifname dummy1
> 3. nmcli dev connect dummy1
>
> Actual results:
> 1. Error: Failed to add 'dummy0' connection: connection.interface-name: property is missing

I think this is expected. A interface name is required for virtual
devices. For some virtual devices like bridges, bonds, teams if
the user doesn't provide an interface name, nmcli generates it:

 # nmcli connection add type bridge con-name bridge+
 Connection 'bridge+' (7f269797-d9f8-42de-9af1-e4a2e18fc62e) successfully added.
 # nmcli -g connection.interface-name connection show bridge+
 nm-bridge

But this behavior doesn't work for all devices and also doesn't seem
particularly useful, because once the user has generated this bridge
with an unknown name, it must discover what name was generated to set
it in slave connections.

> 2.1 if dummy0 is of type dummy, it activates on device saved in connection dummy0, not device dummy1
> 2.2 if dummy0 is of type generic: Error: device 'dummy1' not compatible with connection 'dummy0': The connection was not a dummy connection..
>
> 3. Error: Failed to add/activate new connection: A 'dummy' setting is required.

Steps 2 and 3 assume that the interface-name of a dummy can be unset,
which is not the case (at least, currently).

> Expected results:
> cases above should work without error
>
> Additional info:
> in step 1.) if connection.interface-name '*' is used, then NM add connection, but creates new device named '*'

Yeah, for historical reasons "ifname '*'" means an empty interface
name. If you use the full property name, no conversion is done and the
actual value is used; a interface name of '*' is legitimate.

(In reply to Beniamino Galvani from comment #1)
> >
> > 3. Error: Failed to add/activate new connection: A 'dummy' setting is required.
> 
> Steps 2 and 3 assume that the interface-name of a dummy can be unset,
> which is not the case (at least, currently).

I agree with your comments, that steps 1 and 2 are not supposed to work on virtual devices.

However, step 3 (nmcli dev connect dummy1) does not assume interface-name to be unset. It does not work, even if there is a dummy connection that has interface-name set to dummy1 and is currently down. The problem might be, that NM for dummy connection always creates its dummy interface itself, and can not therefore work with dummy interface created outside NM. If this is a case, please feel free to close this, as it is not a bug.

(In reply to Filip Pokryvka from comment #3)
> However, step 3 (nmcli dev connect dummy1) does not assume interface-name to
> be unset. It does not work, even if there is a dummy connection that has
> interface-name set to dummy1 and is currently down. The problem might be,
> that NM for dummy connection always creates its dummy interface itself, and
> can not therefore work with dummy interface created outside NM. If this is a
> case, please feel free to close this, as it is not a bug.

For some virtual interfaces (for example, veths) "nmcli device connect" creates a new connection and activates it. It would be easy to make it work also for dummy interfaces. I will prepare a patch.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/915

merged to `main` with [1].

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e16c50f507703f15a550b4ef80448dcbd3a85131


this is no material to backport to nm-1-32, rhel-8.5 or rhel-9.0-beta.

Instead, it will be in 1.34.0+, rhel-8.6+ and rhel-9.0-GA.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1985