At a few places we checked whether neighbor->attrs was non-NULL.
That is not necessary, unless we'd like to catch some dangling/invalid
pointers. The attrs hash is always set otherwise.
Instead of just dropping the check, add a NM_IS_LLDP_NEIGHBOR() macro
(inline function).
It's called NM_MORE_ASSERTS not WITH_MORE_ASSERTS.
Also, NM_MORE_ASSERTS is always enabled. It's wrong to check whether it
is defined.
Fixes: e1e428b21e
For one, just reassigning copy->attrs leaks the previous
hash table. Fix that.
Also, NMLldpNeighbor instances are not immutable. I think that
is an uglyness, and it would be preferable that they can be sealed.
A sealed object could safely share/ref the internal hash-table. However,
as it is, we cannot just have two NMLldpNeighbor instances share the
same hash-table. Do a full copy.
Add support for IEEE 802.3 organizationally specific TLVs:
- MAC/PHY configuration/status (IEEE 802.1AB-2009 clause F.2)
- power via medium dependent interface (clause F.3)
- maximum frame size (clause F.4)
Previously we exported the contents of VLAN Name TLV in the 'vid'
(uint32) and 'vlan-name' (string) attributes. This is not entirely
correct as the TLV can appear multiple times.
We need a way to export all the VLAN IDs and names for the
neighbor. Add a new 'vlans' attribute which obsoletes the other two
and is an array of dictionaries, where each dictionary contains the
'vid' and 'name' keys.
Support the management address TLV (IEEE 802.1AB-2009 clause
8.5.9). The TLV can appear multiple times and so it is exported on
D-Bus as an array of dictionaries.
Add the const qualifier to the attribute name in LLDP API functions so
that const strings and string literals are accepted. This change is
backwards compatible for existing users of the API.
If we surprise-remove the master, slaves would immediately attempt to bring
things up by autoconnecting. Not cool. Policy, however, blocks
autoconnect if the slaves disconnect due to "dependency-failed", and it
indeed seems to be an appropriate reason here:
$ nmcli c add type bridge
$ nmcli c add type dummy ifname dummy0 master bridge autoconnect yes
$ nmcli c del bridge
$
Before:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> disconnected (reason 'connection-removed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
policy: auto-activating connection 'bridge-slave-dummy0'
After:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> deactivating (reason 'dependency-failed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: deactivating -> disconnected (reason 'dependency-failed')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
https://github.com/NetworkManager/NetworkManager/pull/319
Setting one property might affect multiple properties.
For example, setting a team property might also emit property changed
signal for "team.config".
Or, one property might be modified multiple times. For example list
properties may first clear the property, then append multiple elements.
Or a list property might remove multiple elements.
Combine these signals via g_object_freeze_notify() and
g_object_thaw_notify().
There is no reason to validate only in certain cases. Either we
validate, or we don't (always the same).
This is a change in behavior, but the cases should be sensible.
Most GObject properties default to FALSE/NULL/0. In that case, there
is no difference between setting the default or clearing the value.
During
if (_SET_FCN_DO_RESET_DEFAULT (property_info, modifier, value))
return _gobject_property_reset_default (setting, property_info->property_name);
it is correct to reset the default.
However for list-typed properties, we want to clear the list. So,
it should be
if (_SET_FCN_DO_SET_ALL (modifier, value))
_gobject_property_reset (setting, property_info->property_name, FALSE);
The VFs already can be parsed as plain number (to indicate the
ifindex). We should not also support accepting the plain number
as index to be removed.
Fixes: a2f12994b7 ('cli: add support for configuring SR-IOV')
$ nmcli connection modify "$PROFILE" -ipv4.addresses 1,3
Already before, nmcli would support removing items by index. But only
one number was supported.
- indexes are zero based (as before).
- duplicate indexes or indexes out of bounds are silently ignored.
Maybe certain properties should not support removal by index.
Use new ValueStrsplitMode "VALUE_STRSPLIT_MODE_STRIPPED".
Note that this is not exactly what we did before. For example, empty
tokens are now silently removed.
Also, we accept now whitespace as separators.
Have one function that gets all the nonesense right. "nonesense", because
we have inconsistent behaviors, and the function is supposed to help with
that.
set_fcn() and remove_fcn() are strongly related. They should accept
arguments in the same format, hence the parsing of the arguments should
be done at one place.
In fact, previously the parsing was separate, leading to ugly
inconsistencies:
$ nmcli connection modify "$PROFILE" +vpn.data x=y
$ nmcli connection modify "$PROFILE" -vpn.data x=y
Error: failed to remove a value from vpn.data: invalid option 'x=y'.
or
$ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24
$ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24
Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed.
Let set_fcn() handle set-default, set-all, add, and subtract.
Previously, set_fcn() could only append values. Now, pass on the modifier
so that it may append, set all, or reset the default.
These operations are strongly related and should be handled by the same
set_fcn() function.
