src/core/initrd/tests/test-cmdline-reader.c: In function test_if_off:
src/core/initrd/tests/test-cmdline-reader.c:564:5: error: for loop initial declarations are only allowed in C99 mode
for (int i = 0; i < G_N_ELEMENTS(conn_expected); ++i) {
^
src/core/initrd/tests/test-cmdline-reader.c:564:5: note: use option -std=c99 or -std=gnu99 to compile your code
If the modem is connected, and registrations drops, and then is restored, the
connection isn't re-activated.
The fix was simply to change modem_state_cb to not return after setting the
state to failed, which allows nm_device_queue_recheck_available to be called,
which queues a state transition to UNAVAILABLE.
This patch fixes two issues,
- If ofono returns InProgress, don't treat as a PREPARE_FAILURE.
- If context in question is already active, instead of trying to wait
for "Active" property to change, check the current state of context
properties, and if it is Active = true, fetch the rest of context
settings and process them
Original bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1565717
Co-Authored-by: Bhushan Shah <bshah@kde.org> [rebase patch to upstream,
and adjust it to newer coding style]
The libnm API NMLldpNeighbor does not accept "" as an attribute name.
And it does not need to, because a reasonable NetworkManager should
never expose such names.
However, we should not trust NetworkManager to be reasonable. Check that
the attribute name is not empty.
There is no public API to modify a NMLldpNeighbor instance. They are only
created by NMDevice and afterwards immutable. There is no point to duplicate
them, when we can just take a ref.
Note that this means we must be careful if we ever add API to mutate a
NMLldpNeighbor. But immutable types are awesome, so we probably should
never do that anyway.
At least ref-counting should be thread safe for our public API.
Note that NMLldpNeighbor has no public API for mutating a neighbor
instance. Especially for immutable types, it is very attractive that
ref-counting is thread-safe.
Also use slice allocator for NMLldpNeighbor structs.
If an existing connection has an interface name set and the generator
finds a BOOTIF argument, it creates a new connection for BOOTIF.
Instead, the generator should set the MAC in the existing connection;
this sounds more correct and it is what the network-legacy module
does.
https://bugzilla.redhat.com/show_bug.cgi?id=1915493
802-1x.optional=yes means that NM should tolerate a failure or a
timeout of the 802.1X authentication and should keep the connection
up. Even if the authentication doesn't succeed, NM keeps the
supplicant running so that it can continue trying.
If the supplicant disappears because it crashed or was killed
externally, NM should fail the connection so that it can be retried.
The current code is wrong also because after releasing the supplicant
interface, it calls wired_auth_cond_fail() which tries to connect a
signal to priv->supplicant.iface (which is NULL).
https://bugzilla.redhat.com/show_bug.cgi?id=1934291https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/776
Currently we unconditionally reset the MAC to the previous value after
releasing ports. This has some disadvantages:
- by default, after the last port is removed the bond will have one
of the previous port's address, which could conflict with the port;
- in some cases, changing the bond MAC is not possible. For example
when the bond is active-backup and has fail_over_mac=1|2. In such
case the netlink call succeeds, but the address doesn't
change; then NM would keep waiting for some time.
Don't try to restore the MAC unless the bond connection has a cloned
MAC set.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/775
We have a cache for sysctl values, so that we can log changes and
previous values.
When resetting the log level, we prune that cache, which is done by
_nm_logging_clear_platform_logging_cache(). That function is called
by nm_logging_setup(), which is guaranteed to only happen on the main
thread.
NMPlatform in general is not thread safe (meaning, that the same NMPlatform
instance cannot be used by multiple threads at the same time). There is however
a reasonable aim that you could use different NMPlatform instances on their
own threads.
That currently doesn't work, mainly due to nm-logging which always must
be done from the main thread -- unless we would set NM_THREAD_SAFE_ON_MAIN_THREAD
in all of NMPlatform (which would be too expensive for something we
don't actually need). That means also the sysctl getter must only be
called on the main thread an all was good already.
Still, we could have NMPlatform usable from multiple thread by setting
NM_THREAD_SAFE_ON_MAIN_THREAD. As we are almost there to have the code
thread-safe, make accessing the sysctl value cache thread-safe (even if
we currently don't actually access it from multiple thread).
The idea of NM_G_MUTEX_LOCKED() macro is not only to register a mutex
for unlocking (via nm_auto_unlock_g_mutex) but also to lock it at
the same time.
That is a useful helper macro. If you have to lock the mutex yourself,
it makes usage less convenient. At which point you don't need the macro
anymore and you should instead take full control and lock/unlock yourself.
Fix the macro and change behavior. The macro was not used so far, so
it's not a problem.
Fixes: dd33b3a14e ('shared: add nm_auto_unlock_g_mutex and NM_G_MUTEX_LOCKED() helper macros')
In core, NMPlatform is (also) a singleton instance. As we will move platform code
to libnm-platform, this singleton part makes no sense there. Move the code
to NetworkManagerUtils.c.
