We aim to keep the platform cache up-to-date only via the netlink
events. However, due to kernel shortcomings we often have to resync
by re-requesting the data, which especially for routes and addresses
means a full dump (as you cannot request only specific route/address
information).
Thus it makes sense to avoid expensive dumps whenever we can.
We schedule dumps via "delayed-actions" and that is already smart
so that muliple schedulings are combined. However, before requesting
a new dump, we clear the flag that indicates that a dump is scheduled.
Thus, while processing the result of of a dump, we would re-schedule
anew which can be necessary in some cases.
In certain cases, we don't require a full resync, when we are in the
middle of processing a dump, because that one dump will provide us
with the full picture. Thus, we can avoid scheduling a new dump if
- we already scheduled a delayed action
- we are in the middle or processing a dump.
This can now be checked via delayed_action_refresh_all_in_progress().
Instead of returning only TRUE/FALSE, return the number of signals
that were received while waiting. This make the API cleared, because
previously I always had to check anew whether wait-for-signal returns
TRUE or FALSE on timeout.
Also, add nmtstp_assert_wait_for_signal() and nmtstp_assert_wait_for_signal_until()
macros.
This allows tests to use these functions on a different platform instance
then on the singleton. The change makes the argument list longer, which is
unfortunate. On the other hand, it makes those functions more useful
in general.
You can't have it all.
Also, they now follow the pattern of most functions in NM where the type
is a singleton: you always pass the singleton to the function, although
in the usual case there is only one singleton instance. This allows to
use the function also on the non-singleton instance.
NMPCacheId is a union with fields for all known NMPCacheIdTypes.
Up to now, we always cloned the entire union, computed the hash
over all (possibly unset) fields and used memcmp() unanimously.
That was ok, because NMPCacheId was 16 bytes in total and cache-id
types that consumed less bytes didn't have a large overhead.
Next, we will add a new cache id type which increases the size of
NMPCacheId to 24 bytes. So, while possibly only a fraction of the
instances is that large, they would all have to pay that price.
Change that to consider and clone only those parts of the id
that are actually used.
As we get more NMPCacheIdType values, it's better to have for
each type a pre-declared list of supported types, instead of
iterating over all types and letting _nmp_object_init_cache_id()
figure out that the cache-id-type is unsupported on that object.
NM_UTILS_LOOKUP_DEFAULT_NM_ASSERT() is useful because unless
compiled with NM_MORE_ASSERTS, there is no assertion.
An assertion includes the function name, and can make the
function ineligible for inlining.
Since long, dnsmasq supports scoping the IPv6 address
with '@<interface-name>'. Since 2.58, it also supports
'%' as delimiter, which is the standard way to specify
the zone-id (rfc6874).
Since 2.73, specifying the scope with '@' as "server"
address is no longer working properly, thus breaking
NetworkManager with dnsmasq >= 2.73.
To work around that, use '%' delimiter. That breaks pre-2.58
users that have a DNS server on a link local address, but that
seems acceptable as that version was released in January 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=764839
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
An externally configured software device is considered external-down until
it is IF_UP and has IP configuration.
When the user explicitly manages the device via UDEV rule, that decision
should overrule external-down.
The applied connection must not be modified during the activation. If
the PPP setting needs to be changed when activating a PPPoE
connection, make a copy to prevent the following error:
could not get secrets:
GDBus.Error:org.freedesktop.NetworkManager.Settings.Failed:
The connection was modified since activation
https://bugzilla.redhat.com/show_bug.cgi?id=1324895
Valgrind doesn't like it, so don't use g_file_copy().
==10410== Syscall param ioctl(generic) points to unaddressable byte(s)
==10410== at 0x82E1707: ioctl (syscall-template.S:84)
==10410== by 0x7712E71: btrfs_reflink_with_progress (gfile.c:3012)
==10410== by 0x7712E71: file_copy_fallback (gfile.c:3186)
==10410== by 0x7712E71: g_file_copy (gfile.c:3394)
==10410== by 0x1350CA: test_config_state_file (test-config.c:948)
==10410== by 0x7D0845A: test_case_run (gtestutils.c:2158)
==10410== by 0x7D0845A: g_test_run_suite_internal (gtestutils.c:2241)
==10410== by 0x7D08622: g_test_run_suite_internal (gtestutils.c:2253)
==10410== by 0x7D0882D: g_test_run_suite (gtestutils.c:2328)
==10410== by 0x7D08850: g_test_run (gtestutils.c:1596)
==10410== by 0x12EFA4: main (test-config.c:1032)
==10410== Address 0x9 is not stack'd, malloc'd or (recently) free'd
==10410==
Fixes: e3a30665d7
After all, this state is stored persistently to /var/lib/NetworkManager,
and not to volatile storage in /var/run. Hence the name is better.
It's also shorter, so rename it.
The commit is mostly trivial, including update of code comments
and logging messages.
Fixes: 1b43c880ba
Move reading and writing of the state file to NMConfig
("/var/lib/NetworkManager/NetworkManager.state" file).
Originally, I intended to persist more state, thus it made
sense to cleanup handling of the state file and move it all
at one place. Now, it's not clear that will happen anytime soon.
Still, the change is a worthy cleanup, so do it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=764474
