If the tracked device is a control device only (has no network interface)
like in the case of a cdc-wdm device, get the mtu from the ip interface
(the exposed wwan network interface in this case).
https://bugzilla.redhat.com/show_bug.cgi?id=1460217
/proc/sys might be read-only but we want to set it for
enabling shared mode.
Check first if the sysctl already has the expected value,
and if so, do nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=790726
Also downgrade a few intermediate error logging messages
for failures that happen while start_sharing(). A debug
message is enough in this case, because we propagate now
the error to the caller, which logs a warning anyway.
We should use the same str2bool parser everywhere: _nm_utils_ascii_str_to_bool().
Incidentally, this function allows more forms of expressing a boolean
value.
$ nmcli connection modify "$CON" ipv4.routes '1.2.3.4/32 1.2.3.1 onlink=1'
Error: failed to modify ipv4.routes: invalid option 'onlink=1': invalid boolean value '1' for attribute 'onlink'.
We cannot just call g_object_set() with an integer that is out of bound.
Otherwise, glib will warn. We can use nm_g_object_set_property*() to return
an error without asserting.
Currently both bridge.mac-address and ethernet.cloned-mac-address get
written to the same MACADDR ifcfg-rh variable; the ethernet property
wins if both are present.
When one property is set and the connection is saved (and thus reread)
both properties are populated with the same value. This is wrong
because, even if the properties have the same meaning, the setting
plugin should not read something different from what was written. Also
consider that after the following steps:
$ nmcli con mod c ethernet.cloned-mac-address 00:11:22:33:44:55
$ nmcli con mod c ethernet.cloned-mac-address ""
the connection will still have the new mac address set in the
bridge.mac-address property, which is certainly unexpected.
In general, mapping multiple properties to the same variable is
harmful and must be avoided. Therefore, let's use a different variable
for bridge.mac-address. This changes behavior, but not so much:
- connections that have MACADDR set will behave as before; the only
difference will be that the MAC will be present in the wired
setting instead of the bridge one;
- initscripts compatibility is not relevant because MACADDR for
bridges was a NM extension;
- if someone creates a new connection and sets bridge.mac-address NM
will set the BRIDGE_MACADDR property instead of MACADDR. But this
shouldn't be a big concern as bridge.mac-address is documented as
deprecated and should not be used for new connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1516659
Previously, g_hash_table_get_keys() would already allocate a
GList list, which then gets copied to another GSList.
Don't do that. Just allocate one array to keep all the
elements.
Also, as we now use nm_setting_vpn_get_secret_keys() and
nm_setting_vpn_get_data_keys(), note that the keys are sorted
and hence the order is stable.
It's rather limiting that the only API to access *all* keys
is nm_setting_vpn_foreach_data_item() and nm_setting_vpn_foreach_secret().
API like nm_setting_vpn_get_num_secrets() is not useful, at least as
long as you cannot access the item by index.
There is no principle problem with returning zero has hash
value. But just don't do it. Our hash functions should not
return zero. Instead, return nm_hash_static(). This is why
the function exists.
GNU less supports filters. That makes it nice to use instead of cat.
Also, less is well suited for output to a pipe.
With this, `NM-log nm-log.txt.gz` works as you would expect
