The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
Normalizing can be complicated, as settings depend on each other and possibly
conflict.
That is, because verify() must exactly anticipate whether normalization will
succeed and how the result will look like. That is because we only want to
modify the connection, if we are sure that the result will verify.
Hence, verify() and normalize() are strongly related. The implementation
should not be spread out between NMSettingOvsInterface:verify(),
NMSettingOvsPatch:verify() and _normalize_ovs_interface_type().
Also, add some unit-tests.
- clearify in the manual page that setting retry to 1 means to try
once, without retry.
- log the initially set retry value in nm_settings_connection_get_autoconnect_retries().
- use nm_settings_connection_get_autoconnect_retries() in
nm_settings_connection_can_autoconnect().
Using plain numbers make it cumbersome to grep for
setting types by priority.
The only downside is, that with the enum values it
is no longer obvious which value has higher or lower
priority.
Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
_nm_setting_type_get_base_type_priority() returns. For the moment
it still has the same numerical value 0 as before. Later, that
shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
When the two base settings are present, use one of higher priority.
This will pick the "bridge" setting when both "bridge" and "bluetooth" are
present for a Bluetooth NAP connection.
Having a bridge-port/team-port setting for a connection that
has a different slave-type makes no sense. Such a configuration
shall be considered invalid, and be fixed by normalization.
Note that there is already a normalization the other way around,
when you omit the "slave-type" but a "master" and one(!) port-type
setting is present, the slave-type is automatically determined
based on the port-type.
The use of this is of course to modify an existing slave connection
to make it a non-slave. Then the invalid port settings should be
automatically removed.
Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting
without a "BRIDGE". The reader would then (correctly) ignore the
bridge-port. Avoid that altogehter, by requiring the connection to
strictly verify.
Usecase: when connecting to a public Wi-Fi with MAC address randomization
("wifi.cloned-mac-address=random") you get on every re-connect a new
IP address due to the changing MAC address.
"wifi.cloned-mac-address=stable" is the solution for that. But that
means, every time when reconnecting to this network, the same ID will
be reused. We want an ID that is stable for a while, but at a later
point a new ID should e generated when revisiting the Wi-Fi network.
Extend the stable-id to become dynamic and support templates/substitutions.
Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
Any unrecognized pattern is treated verbaim/untranslated.
"$$" is treated special to allow escaping the '$' character. This allows
the user to still embed verbatim '$' characters with the guarantee that
future versions of NetworkManager will still generate the same ID.
Of course, a user could just avoid '$' in the stable-id unless using
it for dynamic substitutions.
Later we might want to add more recognized substitutions. For example, it
could be useful to generate new IDs based on the current time. The ${} syntax
is extendable to support arguments like "${PERIODIC:weekly}".
Also allow "connection.stable-id" to be set as global default value.
Previously that made no sense because the stable-id was static
and is anyway strongly tied to the identity of the connection profile.
Now, with dynamic stable-ids it gets much more useful to specify
a global default.
Note that pre-existing stable-ids don't change and still generate
the same addresses -- unless they contain one of the new ${} patterns.
We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the
network.service did, confusing the legacy tooling. Let's do our best to write
compatible configuration files:
* Add *_UUID properties that won't clash with initscripts
* Ignore non-*_UUID keys on read if *_UUID is present
* If the connection.master is an UUID of a connection with a
connection.interface-name, write the uuid into the *_UUID key while setting
the non-*_UUID key to the interface name for compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
While technically it's already possible to implement a fail-over
mechanism using multiple connections (for example, defining a higher
priority DHCP connection with short DHCP timeout and a lower priority
one with static address), in practice this doesn't work well as we try
to autoactivate each connection 4 times before switching to the next
one.
Introduce a connection.autoconnect-retries property that can be used
to change the number of retries. The special value 0 means infinite
and can be used to try the connection forever. A -1 value means the
global configured default, which is equal to 4 unless overridden.
https://bugzilla.gnome.org/show_bug.cgi?id=763524
Backported symbols only make sense for libnm itself, not for
libnm-core which is statically linked with NetworkManager and
nm-ifcace-helper. Declaring the symbols in libnm-core, means
that NetworkManager binary also contains them, although there
are not used.
Move them to libnm.
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
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.
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).
In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.
Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.
Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.
For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.
This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
Add the 'lldp' property to NMSettingConnection, which specifies
whether the reception and parsing of LLDP frames to discover neighbor
devices should be enabled.
API should be added with "Since:" of the next release on the same branch.
That means, new API on 1.1 branch (development), should be "Since: 1.2"
and new API on 1.0 branch (stable) will be "Since: 1.0.x". Similarly, new
API on master is NM_AVAILABLE_IN_1_2 and will be added with the linker
version libnl_1_2 -- never the versions of minor releases.
It is also strongly advised that for the 1.0 branch, we only add API
that was previously formerly added on master. IOW, that we only do true
backports of API that already exists on master.
API that gets backported, must also be added to master via NM_BACKPORT_SYMBOL().
That gives ABI compatibility and an application that was build against 1.0.x
will work with 1.y.z version (y > 0) without need for recompiling -- provided
that 1.y.z also contains that API.
There is one important caveat: if a major branch (e.g. current master) has a
linker section of backported APIs (e.g. libnm_1_0_6), we must do the minor release
(1.0.6) before the next major release (1.2). The reason is that after the major
release, the linker section (libnm_1_0_6) must not be extended and thus
the minor release (1.0.6) must be already released at that point.
In general, users should avoid using backported API because it limits
the ability to upgrade to arbitrary later versions. But together with the
previous point (that we only backport API to minor releases), a user that
uses backported API can be sure that a 1.y.z version is ABI compatible with
1.0.x, if the 1.y.z release date was after the release date of 1.0.x.
This reverts commit 02a136682c.
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
When ping is launched to check the connectivity to the gateway it may
return earlier than the given timeout in case of error. When this
happens we need to respawn it until the timeout is reached.
While at it, increase maximum timeout value to 600 seconds.
https://bugzilla.redhat.com/show_bug.cgi?id=1128581
AUTOCONNECT_SLAVES is an NetworkManager extension. initscripts always activate
slaves with the master connection for bond and team, and doesn't activate
automatically slaves for bridge.
NetworkManager behaviour is controlled by this variable. If the variable is
missing the default value from configuration file is used.
The property is used for controlling whether slaves should be brought up with
a master connection. If 0, activating the master will not activate slaves.
But if set to 1, activating the master will bring up slaves as well.
The property can have the third state (-1), meaning that the value is default.
That is either a value set in the configuration file for the property, or 0.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
