It can go away before the activation finishes:
(process:378): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
Thread 1 "lt-nmcli" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff4fa919b in g_logv () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff4fa919b in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff4fa930f in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007ffff529b3ea in g_type_check_instance () at /lib64/libgobject-2.0.so.0
#3 0x00007ffff528fa94 in g_signal_handlers_disconnect_matched () at /lib64/libgobject-2.0.so.0
#4 0x000000000041ae4e in activate_connection_info_finish (info=0x7b5490) at connections.c:2197
#5 0x00007ffff5279470 in g_cclosure_marshal_VOID__OBJECTv () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff5276617 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff5290ea9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#8 0x00007ffff52914ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#9 0x00007ffff52763e8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff52884a2 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff529112d in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff52919ab in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#13 0x00007ffff78fc9b1 in deferred_notify_cb (data=<optimized out>) at nm-object.c:243
#14 0x00007ffff4fa2703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#15 0x00007ffff4fa2ab0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#16 0x00007ffff4fa2dd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#17 0x00000000004146e3 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:618
(gdb) print info->device
On 32-bit architectures long and int have the same size and thus it's
wrong to use nmc_string_to_int() since it uses strtol() and the @max
argument can't represent G_MAXUINT32. Use nmc_string_to_uint()
instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1350201
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
This new property be used as token to generate stable-ids instead
of the connection's UUID.
Later, this will be used by ipv6.addr-gen-mode=stable-privacy,
ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable
setting. Those generate stable addresses based on the connection's
UUID, but allow to use the stable-id instead.
This allows multiple connections to generate the same addresses
-- on the same machine, because in the above cases a machine
dependant key is also hashed.
This would fix for example:
nmcli e <TAB>
(e interpreted as --escape, would allow autocompletion to work... but
when the command is executed an error is reported)
Moreover, we will now have:
nmcli c <TAB>
autocompletion work correctly, i.e., c is correctly interpreted as
"connection" instead of "--colors"
When NM looks for vpn plugins, it would expect the full service name
otherwise it will not be able to retrieve the correct plugin.
Fixes VPN configurations generated with "nmcli connection add".
Re-enable the check on ambiguos properties but this time manage perfect
matches (i.e., the full property name has been typed) that are prefix
of other properties.
Test case:
nmcli --complete-args connection add type wifi wifi.
Here "wifi" is a property alias that is also prefix of the property
alias "wifi-sec".
