Although we don't really need protect for thread safety in _nm_utils_init(),
avoid using static variables without lock/atomic operations. libnm is not
thread-safe, but we still should try to avoid potential issues whenever it is
easy.
constructor functions are ugly, because code is running before
main() starts. Instead, as the registration code for NMSetting types
is insid the GType constructor, we just need to ensure at the
right place, that the GType was created.
The right place here is _register_settings_ensure_inited(), because
that is called before we need the registration information.
_nm_register_setting() and _nm_register_setting_impl() are called from within
the GType constructor for the NMSetting subtype. As such, at that point it
runs inside a g_once_init_enter() block. However, each implementation
for initializing the GType has a separate g_once_init_enter() variable, hence,
if two threads create GType instances for different NMSetting subclasses, there
is a race.
libnm is not thread safe. However, it should be at least thread safe
with respect to constructing the GType instances.
For NMSetting subtypes, we need the static dictionaries "registered_settings" and
"registered_settings_by_type" to keep track of existing NMSetting types.
Initialize these dictionaries inside NMSetting's type initialization code.
This is guaranteed to run before any use of NMSetting type, and is also
guarded by a mutex.
Also, drop the __attribute__((constructor)) function to initialize the
hash tables. They are not needed, and it's ugly to run code before
main().
It's for 6LoWPAN devices. "o.fd.NM.Device.6Lowpan" wouldn't be a valid
interface name -- just skip the leading numeral, that's what kernel also
does on similiar occassions.
For some device types it's not going to be sufficient to tell whether
they carry "IP".
In particular, there's no way to carry legacy IP over the tiny MTU
datagrams of IEEE 802.15.4 WPAN links while an IPv6 transport exist
in form of 6LoWPAN.
A configuration with duplicate tc qdiscs and tfilters is not valid;
reject it in verify(). Note that nm_setting_tc_config_add_qdisc() and
nm_setting_tc_config_add_tfilter() can't add duplicate entries and so
the only way to achieve an invalid configuration is setting the
properties directly.
https://github.com/NetworkManager/NetworkManager/pull/95
When link auto-negotiation is enabled, by default the network device
advertises all the supported speed and duplex modes in order to
negotiate the fastest link speed with the remote endpoint.
It is possible anyway to configure the device to just advertise and
accept a subset of supported modes.
This could be useful to properly enforce gigabit speeds on Ethernet:
as stated in IEEE 802.3 specification, auto-negotiation is mandatory
for 1000Base-T and 10GBase-T standards.
Allow specific values to 802-3-ethernet.speed and 802-3-ethernet.duplex
properties also when 802-3-ethernet.auto-negotiate=yes: this will
result in link auto-negotiation advertising the specified speed/duplex
mode as the only one available.
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
In a lot of cases, we don't require the GBytes out-argument. This
is the case when called from NMSettingIP6Config's verify().
Avoid allocating the GBytes instance and also don't heap allocate
the temporary buffer in that case.
Also, being called from NMSettingIP6Config's verify(), at which
point the string value contains untrusted data. Of course, we
do very badly in general protecting against the user creating
huge settings, which could trick NetworkManage to allocate
large amounts of memory (and being killed by glib's out of memory
handling). We should handle such cases better in general, but
just avoid it here.
Since we know that the buffer must hold at most 128+2 bytes,
we can stack allocate it. Later, in case we really need to
return the value, we can create a GBytes instance of the right
size.
allow to specify the DUID to be used int the DHCPv6 client identifier
option: the dhcp-duid property accepts either a hex string or the
special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
"stable-uuid".
"lease": give priority to the DUID available in the lease file if any,
otherwise fallback to a global default dependant on the dhcp
client used. This is the default and reflects how the DUID
was managed previously.
"ll": enforce generation and use of LL type DUID based on the current
hardware address.
"llt": enforce generation and use of LLT type DUID based on the current
hardware address and a stable time field.
"stable-ll": enforce generation and use of LL type DUID based on a
link layer address derived from the stable id.
"stable-llt": enforce generation and use of LLT type DUID based on
a link layer address and a timestamp both derived from the
stable id.
"stable-uuid": enforce generation and use of a UUID type DUID based on a
uuid generated from the stable id.
The files in shared/nm-utils are not compiled as one static library,
instead each subproject that needs (parts of) them, re-compiles the
files individually.
The major reason for that is, because we might have different compile
flags, depending on whether we build libnm-core or
libnm-util/libnm-glib. Actually, I think that is not really the case,
and maybe this should be refactored, to indeed build them all as a
static library first.
Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
different set of shared files that they should compile. Refactor
"shared/meson.build" to account for that and handle it like autotools
does.
Another change is, that "shared_c_siphash_dep" no longer advertises
"include_directories: include_directories('c-siphash/src')". We don't
put c-siphash.h into the include search path. Users who need it, should
include it via "#include <c-siphash/src/c-siphash.h>". The only exception
is when building shared_n_acd library, which is not under our control.
Originally, we used "nm-utils/siphash24.c", which was copied
from systemd's source tree. It was both used by our own NetworkManager
code, and by our internal systemd fork.
Then, we added "shared/c-siphash" as a dependency for n-acd.
Now, drop systemd's implementation and use c-siphash also
for our internal purpose. Also, let systemd code use c-siphash,
by patching "src/systemd/src/basic/siphash24.h".
Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR
for specifying the location of srcdir and builddir.
Note that this is only relevant for tests, as they expect
a certain layout of the directories, to find files that concern
them.
Add new stable-id specifier "${DEVICE}" to explicitly declare that the
connection's identity differs per-device.
Note that for settings like "ipv6.addr-gen-mode=stable" we already hash
the interface's name. So, in combination with addr-gen-mode, using this
specifier has no real use. But for example, we don't do that for
"ipv4.dhcp-client-id=stable".
Point being, in various context we possibly already include a per-device
token into the generation algorithm. But that is not the case for all
contexts and uses.
Especially the DHCPv4 client identifier is supposed to differ between interfaces
(according to RFC). We don't do that by default with "ipv4.dhcp-client-id=stable",
but with "${DEVICE}" can can now be configured by the user.
Note that the fact that the client-id is the same accross interfaces, is not a
common problem, because profiles are usually restricted to one device via
connection.interface-name.
Otherwise, the generated client-id depends purely on the profile's
stable-id. It means, the same profile (that is, either the same UUID
or same stable-id) on different hosts will result in identical client-ids.
That is clearly not desired. Hash a per-host secret-key as well.
Note, that we don't hash the interface name. So, activating the
profile on different interfaces, will still yield the same client-id.
But also note, that commonly a profile is restricted to one device,
via "connection.interface-name".
Note that this is a change in behavior. However, "ipv4.dhcp-client-id=stable"
was only added recently and not yet released.
Fixes: 62a7863979
nm_utils_hwaddr_valid() is used for validating strings. It should
not assert against calling it with an empty string "". That is just
an invalid hwaddr.
This makes package updates more robust, avoiding in-place replaces of
the plugins.
Previously, if an upgrade transaction was terminated, NetworkManager
library could end up being of a different version than the plugins.
If the user was unfortunate enough to connect using a connection that
required a plugin (say, Wi-Fi), he would be left without a network
connection making it somewhat inconvenient to recover from the botched
upgrade.
This makes the whole situation a little bit less sad.
The VPN plugins are kept where they always have been -- the path is not
qualified with a version number.
Coccinelle:
@@
expression a, b;
@@
-a ? a : b
+a ?: b
Applied with:
spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.
Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
Do not have multiple ways of expressing a certain thing. There is
a way how to express that the parser shouldn't check for keys, and
that is via the parse-information. No extra hacks.
