The enum defines should name their numerical value explicitly,
so that it can be easily seen by looking at the code. Also,
they are public, stable API. They must not change.
Anyway, the capability 0 shall be reserved. Change NM_CAPABILITY_TEAM
to value 1.
When comparing the bond-settings of an activated device against
the settings from the connection, some properties might easily
differ. Hack them around in NMSettingBond:compare_property().
For example:
the setting in the connection has:
[bond]
mode=active-backup
later, the device gets:
[bond]
active_slave=inf_ib0
fail_over_mac=active
mode=active-backup
Note that the fail_over_mac changes due to:
kernel: nm-bond: enslaved VLAN challenged slave inf_ib0. Adding VLANs will be blocked as long as inf_ib0 is part of bond nm-bond
kernel: nm-bond: The slave device specified does not support setting the MAC address
kernel: nm-bond: Setting fail_over_mac to active for active-backup mode
https://bugzilla.redhat.com/show_bug.cgi?id=1375558
The core only consider the first address for shared connections, don't
pretend we accept multiple addresses. This change doesn't prevent
supporting multiple addresses in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=763937
Long ago before commit 1b49f94, NetworkManager did not touch the
MAC address at all. Since 0.8.2 NetworkManager would modify the
MAC address, and eventually it would reset the permanent MAC address
of the device.
This prevents a user from externally setting the MAC address via tools
like macchanger and rely on NetworkManager not to reset it to the
permanent MAC address. This is considered a security regression in
bgo#708820.
This only changed with commit 9a354cd and 1.4.0. Since then it is possible
to configure "cloned-mac-address=preserve", which instead uses the "initial"
MAC address when the device activates.
That also changed that the "initial" MAC address is the address which was
externally configured on the device as last. In other words, the
"initial" MAC address is picked up from external changes, unless it
was NetworkManager itself who configured the address when activating a
connection.
However, in absence of an explicit configuration the default for
"cloned-mac-address" is still "permanent". Meaning, the user has to
explicitly configure that NetworkManager should not touch the MAC address.
It makes sense to change the upstream default to "preserve". Although this
is a change in behavior since 0.8.2, it seems a better default.
This change has the drastic effect that all the existing connections
out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
I think most users won't notice, because their devices have the permanent
address set by default anyway. I would think that there are few users
who intentionally configured "cloned-mac-address=" to have NetworkManager
restore the permanent address.
https://bugzilla.gnome.org/show_bug.cgi?id=770611
For "cloned-mac-address", the empty string "" is an invalid
value that is rejected by verify().
Commit 8eed671 changed how the property is serialized to D-Bus.
Before, it was serialized using _nm_utils_hwaddr_to_dbus().
For invalid or empty addresses, this would not serialize the
value on D-Bus (or before commit 76aa6f8e0, it would create
a bogus value with no array elements).
With commit 8eed671, the cloned-mac-address gets also serialized
as "assigned-mac-address" via _nm_utils_hwaddr_cloned_data_synth(),
which would pass on invalid strings that the server would then reject.
That breaks for example nmtui. Try editing a connection with
"cloned-mac-address" set to NULL. Note, as long as you don't edit
the cloned MAC address in nmtui, you can save the modification.
Once you start modifying the entry, you can no longer set an empty
MAC address as the server now receives the invalid empty string.
Thus, the "OK" button fails with
Unable to save connection:
802-3-ethernet.cloned-mac-address:
is not a valid MAC address
It also means, nmtui cannot modify the "cloned-mac-address" field to
become empty.
Fix that problem at various places by coercing "" to NULL.
Fixes: 8eed67122chttps://bugzilla.redhat.com/show_bug.cgi?id=1372799
Now that we validate the JSON syntax of a team/team-port
configuration, any existing connection with invalid JSON configuration
would fail to load and disappear upon upgrade. Instead, modify the
setting plugins to emit a warning but still load the connection with
empty configuration.
A user may very well have connections on disk with bogus json.
Such connections may have failed to activate before, but rejecting
them now as invalid means that we stop loading them from disk. That is,
they disappear after upgrade.
Instead of doing that, also accept invalid json (beside "") and
normalize/coerce it to NULL.
https://bugzilla.redhat.com/show_bug.cgi?id=1366300
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
Add statistics interface to all device instances. When active, the
properties of this interface are refreshed whenever there is network
activity for the device.
Activation is performed by changing RefreshRateMs property. If set to
zero, the interface is deactivated. If set to other value, the rest of
the interface properties are refreshed whenever the related network
metric changes, being RefreshRateMs the minimum time between property
changes, in milliseconds.
Even when there's no <secret>-flags key for it in vpn-data.
This is essentially to fix regression in the way openconnect uses the VPN
secrets:
Openconnect auth helper is essentially a web browser that fills in an arbitrary
HTML (or XML) form that's used to get the session cookie. The actual secret the
service needs is the cookie itself.
However, what needs to be remembered includes the form data. What data can be
in the form is installation dependent and can not be known in advance. Thus the
flags for it can't be currently set in the connection. The auth helper is not
capable of setting the flags either, because it can only return secrets.
Prior to 1424f249e we treated vpn.secrets without the flags as system secrets
and store them in the connection. Since that commit we just filter them away,
which broke user configurations.
This restores the behavior or treating everyting in vpn.secrets as secrets and
falling back to system secrets.
Another way would be to find a way to flag the secrets, perhaps by
extending the auth helper protocol to be able to store non-secret
properties too.
https://bugzilla.gnome.org/show_bug.cgi?id=768737
Even if the 'ad_actor_system' option is only valid for the 802.3ad
mode, the sysfs file is always present and has a default value of
''. But in 802.3ad mode the default value is
'00:00:00:00:00:00'. Return the correct value in
nm_setting_bond_get_option_default().
Furthermore, writing a empty string to the file will generate an
error, don't do it.
We print an error when the write of a bond options fails as this is
considered an effect of a wrong configuration (or a bug in the checks
done by NM) that the user should notice. But not all options are
supported in all bonding modes and so we ignore some unsupported
options for the current mode to avoid populating logs with useless
errors.
Improve the code there by using a more generic approach and
synchronize the mode/option compatibility table with kernel (file
drivers/net/bonding/bond_options.c).
https://bugzilla.gnome.org/show_bug.cgi?id=767776https://bugzilla.redhat.com/show_bug.cgi?id=1352131
Since commit 7d1709d7f6 ("device: check may_fail when progressing to
IP_CHECK") NM correctly checks the may-fail properties to decide
whether a connection must fail after the completion of IP
configuration. But for ipv4.method=disabled and ipv6.method=ignore the
IP configuration is always considered failed and thus setting
may-fail=no results in a connection that can never succeed.
To prevent such wrong configuration, force may-fail to TRUE for those
methods during connection normalization.
https://bugzilla.redhat.com/show_bug.cgi?id=1334884
@buf_len is always initialized when @buf_arr is set but gcc fails to
recognize it:
../libnm-core/nm-keyfile-reader.c: In function 'mac_address_parser':
../libnm-core/nm-keyfile-reader.c:654:36: error: 'buf_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
tmp_string = nm_utils_hwaddr_ntoa (buf_arr, buf_len);
Fixes: 8eed67122c
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
_nm_utils_hwaddr_to_dbus() would serialize invalid hardware addresses
as "'cloned-mac-address': <@ay []>".
An empty array is treated the same as no hardware address set,
so we should not serialize it in the first place.
This is a change in behavior on how the connection is exported
on D-Bus, but it should not have any bad consequences.
We need this as we later want to deprecate the 'cloned-mac-address'
D-Bus field and overwrite it via a 'assigned-mac-address' field.
In this case, the "<@ay []>" is interfering. While it could be worked
around by treating an empty MAC address as "unset", fix it instead
and just not serialize it.
When comparing settings, nm_setting_compare() performs a complicated
logic, which basically serializes each GObject property to a GVariant
for the D-Bus representation.
That is wrong for example for ipv4.addresses, which don't contain
address labels. That is, the GObject property is called "addresses",
but the D-Bus field "addresses" cannot encode every information
and thus comparison fails. Instead, it would have to look into
"address-data".
Traditionally, we have virtual functions like compare_property() per
NMSetting to do the comparison. That comparison is based on the GObject
properties. I think that is wrong, because we should have a generic
concept of what a property is, independent from GObject properties.
With libnm, we added NMSettingProperty, which indeed is such an
GObject independent representation to define properties.
However, it is not used thoroughly, instead compare_property() is a hack
of special cases, overloads from NMSettingProperty, overloads of
compare_property(), and default behavior based on GParamSpec.
This should be cleaned up.
For now, just hack it by handle the properties with the problems
explicitly.
The Network_ID for generating RFC 7217 stable privacy IPv6 addresses
is by default the UUID of the connection.
Alternatively, prefer "connection.stable-id" as Network_ID to generate
the stable addresses. This allows to configure a set of connections that
all use the same Network_ID for generating stable addresses.
Note that the stable-id and the UUID do no overlap, that is two
connections
[connection]
uuid=uuid1
stable-id=
and
[connection]
uuid=uuid2
stable-id=uuid1
generate distinct addresses.
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.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.
The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.
The NMVpnPluginInfo is essentially the .name file, that is, a
configuration file about the plugin itself. Via NMVpnPluginInfo
instance, the NMVpnEditorPlugin can be created.
Usually, one would create a NMVpnPluginInfo (that is, reading the
.name file) and then create a NMVpnEditorPlugin instance from there.
In this case, usually the editor-plugin is owned by the plugin-info
instance (although the API allows for creating the editor-plugin
independently).
Now, pass the NMVpnPluginInfo to the editor-plugin too.
This is useful, because then the editor-plugin can look at the .name
file.
The .name file is not user configuration. Instead it is configuration
about the plugin itself. Although the .name file is part of the plugin
build artefacts, it is useful to allow the plugin to access the .name
file. The reason is, that this can allow the user to easily change a
configuration knob of the plugin without requiring to patch or the
plugin.
