The following commit:
b869d9cc0 device: add spec "driver:" to match devices
added two parameters ("driver" and "driver_version") to the
nm_match_spec_device() function.
However, the definition of the function and its declaration are not
consistent.
The prototype shows:
nm_match_spec_device (const GSList *specs,
const char *interface_name,
const char *driver,
const char *driver_version,
const char *device_type,
But the definition shows:
nm_match_spec_device (const GSList *specs,
const char *interface_name,
const char *device_type,
const char *driver,
const char *driver_version,
Since all parameters are pointers to const char, the type checking
succeeds at compile time.
All currently existing invocations of the function are correct and pass
the arguments in the order described in the definition/implementation.
This patch only changes the prototype so that potential future
invocations don't end up buggy.
Fixes: b869d9cc0d
The @connection argument can be NULL; add the (allow-none) annotation
otherwise calling the API with a NULL argument through GObject
introspection fails with:
Argument 1 does not allow None as a value
Fixes: 278fd4fb0f
gretap and ip6gretap ip-tunnel interfaces encapsulate L2 packets over
IP. Allow adding a wired setting for such connections so that users
can change the interface MAC.
Add platform support for IP6GRE and IP6GRETAP tunnels. The former is a
virtual tunnel interface for GRE over IPv6 and the latter is the L2
variant.
The platform code internally reuses and extends the same structure
used by IPv6 tunnels.
Certain platform operations are logged both in nm-platform.c and
nm-linux-platform.c, resulting in duplicate messages. Drop log prints
from the latter.
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().
Add support for a new wireguard link type to the platform code. For now
this only covers querying existing links via genetlink and parsing them
into platform objects.
This disables loading the system-wide dnsmasq from /etc/dnsmasq.conf
and defines to use the NMSTATEDIR device-unique dhcp-leasefile,
preventing it from trampling over others, and isolating it to just
the wifi-ap use.
https://github.com/NetworkManager/NetworkManager/pull/156
`nm-online --wait-for-startup` isn't really intended to be called directly.
It is mainly for implementing "NetworkManager-wait-online.service".
Anyway, at the end, the result does not indicate the connectivty status
of the host. Hence, printing
Connecting............... 30s [online]
is misleading. It merely means, that startup is complete. Likewise,
printing "[offline]" would not mean that there is no connectivity.
Instead, it means that startup is still in progress on timeout.
As it is now, the distinction between whether to print "start-pending"
and "failure" is not very clear. Not that it matters much. At least is
corresponds to the exit status of the program. If we sometimes confuse
EXIT_FAILURE_OFFLINE with other failure reasons, the exit status needs
to be corrected first.
https://github.com/NetworkManager/NetworkManager/pull/152
After 1.12.0 is released, merge it back into master so that
1.12.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.12.0 and 1.12-rc*.
Also bump the micro version to 1.13.1-dev to indicate that this is
after 1.12.0 is out.
In device_ipx_changed() we only keep track of dad6_failed_addrs
addresses if the device's state is > DISCONNECTED.
For the same reason, we should also do that in queued_ip_config_change().
But it's worse. If the device is in state disconnected, and the user
externally adds IPv6 addresses, we will end up in queued_ip_config_change().
It is easily possible that "need_ipv6ll" ends up being TRUE, which results
in a call to check_and_add_ipv6ll_addr() and later possibly
ip_config_merge_and_apply (self, AF_INET6, TRUE);
This in turn will modify the IP configuration on the device, although
the device may be externally managed and NetworkManager shouldn't touch it.
https://bugzilla.redhat.com/show_bug.cgi?id=1593210
(cherry picked from commit 890c748643)
We first iterate over addresses that might have failed IPv6 DAD and
update the state in NMNDisc.
However, while we do that, don't yet invoke the changed signal.
Otherwise, we will invoke it multiple times (in case multiple addresses
failed). Instead, keep track of whether something changed, and handle
it once a bit later.
(cherry picked from commit f312620276)
Whenever we process queued IP changes, we must handle all pending
dad6_failed_addrs. This is, to ensure we don't accumulate more
and more addresses in the list.
Rework the code, by stealing the entire list once at the beginning
dad6_failed_addrs = g_steal_pointer (&priv->dad6_failed_addrs);
and free it at the end:
g_slist_free_full (dad6_failed_addrs, (GDestroyNotify) nmp_object_unref);
This makes it easier to see, that we always process all addresses in
priv->dad6_failed_addrs.
(cherry picked from commit e2c13af805)
There is no change in behavior, however don't handle dad6_failed_addrs
and dad6_ip6_config in the same block.
While both parts are related to IPv6 DAD, they do something rather
different:
- the first block, checks all candidates from dad6_failed_addrs whether
they actually indicate DAD failed, and handles them by notifying
NMNDisc about failed addresses.
- the second block, checks whether we have now all addresses from
dad6_ip6_config that we are waiting for.
Split the blocks.
(cherry picked from commit 3fcdba1a19)
We don't need to cancel the current idle-action and schedule a new
one. Just return and wait to be called again.
Also, drop the logging. Similarly, we don't log the postponing for
the previous case either.
(cherry picked from commit 63cf5bd249)
We also cancel the idle handler
nm_clear_g_source (&priv->queued_ip_config_id_x[IS_IPv4])
which means, nobody is going to process these addresses (at least
for the moment).
The purpose of "dad6_failed_addrs" is to keep track of addresses that
might be interesting for checking about DAD failures. If we are no
longer reacting on IP changes (because the idle handler was removed),
we also no longer need these addresses.
(cherry picked from commit dbb936e5c8)
This simplifies commit 31ca7962f8.
We don't need the boolean flags like "queued_ip4_config_pending" to
track whether we received any platform signals while being not yet
initialized in platform (udev, NM_UNMANAGED_PLATFORM_INIT).
In general, as long as the device is NM_UNMANAGED_PLATFORM_INIT,
all platform signals are ignored. And when the device becomes managed,
we schedule anyway an initial config-change.
(cherry picked from commit 18ecc4b4f1)
In device_ipx_changed() we only keep track of dad6_failed_addrs
addresses if the device's state is > DISCONNECTED.
For the same reason, we should also do that in queued_ip_config_change().
But it's worse. If the device is in state disconnected, and the user
externally adds IPv6 addresses, we will end up in queued_ip_config_change().
It is easily possible that "need_ipv6ll" ends up being TRUE, which results
in a call to check_and_add_ipv6ll_addr() and later possibly
ip_config_merge_and_apply (self, AF_INET6, TRUE);
This in turn will modify the IP configuration on the device, although
the device may be externally managed and NetworkManager shouldn't touch it.
https://bugzilla.redhat.com/show_bug.cgi?id=1593210
We first iterate over addresses that might have failed IPv6 DAD and
update the state in NMNDisc.
However, while we do that, don't yet invoke the changed signal.
Otherwise, we will invoke it multiple times (in case multiple addresses
failed). Instead, keep track of whether something changed, and handle
it once a bit later.
Whenever we process queued IP changes, we must handle all pending
dad6_failed_addrs. This is, to ensure we don't accumulate more
and more addresses in the list.
Rework the code, by stealing the entire list once at the beginning
dad6_failed_addrs = g_steal_pointer (&priv->dad6_failed_addrs);
and free it at the end:
g_slist_free_full (dad6_failed_addrs, (GDestroyNotify) nmp_object_unref);
This makes it easier to see, that we always process all addresses in
priv->dad6_failed_addrs.
There is no change in behavior, however don't handle dad6_failed_addrs
and dad6_ip6_config in the same block.
While both parts are related to IPv6 DAD, they do something rather
different:
- the first block, checks all candidates from dad6_failed_addrs whether
they actually indicate DAD failed, and handles them by notifying
NMNDisc about failed addresses.
- the second block, checks whether we have now all addresses from
dad6_ip6_config that we are waiting for.
Split the blocks.
We don't need to cancel the current idle-action and schedule a new
one. Just return and wait to be called again.
Also, drop the logging. Similarly, we don't log the postponing for
the previous case either.
We also cancel the idle handler
nm_clear_g_source (&priv->queued_ip_config_id_x[IS_IPv4])
which means, nobody is going to process these addresses (at least
for the moment).
The purpose of "dad6_failed_addrs" is to keep track of addresses that
might be interesting for checking about DAD failures. If we are no
longer reacting on IP changes (because the idle handler was removed),
we also no longer need these addresses.
This simplifies commit 31ca7962f8.
We don't need the boolean flags like "queued_ip4_config_pending" to
track whether we received any platform signals while being not yet
initialized in platform (udev, NM_UNMANAGED_PLATFORM_INIT).
In general, as long as the device is NM_UNMANAGED_PLATFORM_INIT,
all platform signals are ignored. And when the device becomes managed,
we schedule anyway an initial config-change.
