Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
Even Fedora is no longer shipping the WiMAX SDK, so it's likely we'll
eventually accidentally break some of the code in src/devices/wimax/
(if we haven't already). Discussion on the list showed a consensus for
dropping support for WiMAX.
So, remove the SDK checks from configure.ac, remove the WiMAX device
plugin and associated manager support, and deprecate all the APIs.
For compatibility reasons, it is still possible to create and save
WiMAX connections, to toggle the software WiMAX rfkill state, and to
change the "WIMAX" log level, although none of these have any effect,
since no NMDeviceWimax will ever be created.
nmcli was only compiling in support for most WiMAX operations when NM
as a whole was built with WiMAX support, so that code has been removed
now as well. (It is still possible to use nmcli to create and edit
WiMAX connections, but those connections will never be activatable.)
No need to parse the subchannels if the spec list is empty.
This isn't actually an issue, because nm_match_spec_s390_subchannels()
was never called with empty spec list.
The configuration snippets are loaded in alphabetical order.
Fix the printed description to reflect that order. Otherwise,
NM logs at startup:
<info> Read config: /etc/NetworkManager/NetworkManager.conf and conf.d: 20-connectivity-fedora.conf, 10-ibft-plugin.conf
We currently don't manage a veth inside a container despite we should because
it's an externally configured software interface and thus waits for IFF_UP.
Given veths are prevented from being managed outside of a container by an udev
rule anyway it's safe to lift the external IFF_UP requirement for them.
Some dual-band access points use the same BSSID in both the 5GHz
and 2.4GHz bands, so obviously frequency must be taken into account
when matching. But no AP should ever use the same SSID/BSSID pair
concurrently in the same band on different frequencies.
Some APs also dynamically channel hop when they detect interference,
or when they restart, they do so on a different channel after finding
the channel with the lowest interference. To assure that we don't
end up with stale scan list entries when the AP has switched to
another channel in the same band, fall back to band matching
when merging new scan results.
The only reason to allow lazy matching was to update a fake
current AP when its real scan result comes in. Now that NM
tracks the current AP based on the the supplicant's current
BSS, a fake current AP will be replaced when the real scan
result arrives. So it's pointless to update the fake one
when it'll just be removed soon.
Instead of keeping track of it internally, and attempting to fuzzy-match
access points and stuff, just use the supplicant's information. If the
supplicant doesn't know what AP it's talking to, then we've got more
problems than just NM code.
The theory here is that when starting activation, we'll use the given
access point from the scan list that the supplicant already knows about.
If there isn't one yet (adhoc, hidden, or AP mode) then we'll create
a fake AP and add it to the scan list.
Once the supplicant has associated to the AP, it'll notify about the
current BSS which we then look up in the scan list, and set
priv->current AP to that. If for some reason the given AP isn't yet
in our scan list (which often happens for adhoc/AP) then we'll just
live with the fake AP until we get the scan result, which should happen
very soon.
We don't need to do any fuzzy-matching to find the current AP because
it will either always be one the supplicant knows about, or a fake one
that the supplicant doesn't know about that will be replaced soon anyway.
The function names in linux-platform should get better prefixes
indicating whether they are related to libnl or nm objects.
Add a prefix _nlo_ for functions that operate on libnl objects.
Refactor the implementation of nm_route_manager_ip4_route_sync()
and nm_route_manager_ip6_route_sync().
- merge the implementations for IPv4 and IPv6.
- pre-sort the routes and iterate them in a way that we don't
need to lookup a route in other lists. Do this by iterating
two sorted lists at a time in a merge-sort way.
The runtime complexity of sync is now O(n*ln(n)).
- previously, the algorithm would merge routes it found in platform
to priv->ipx_routes. That was wrong, because then we loose the
information which routes we wanted to configure internally and which
are present externally.
Instead, priv->ipx_routes now contains all the routes that were
explicitly configured via sync(). Hence, it knows what should be
configured (@ipx_routes) and can compare to what is configured
(@plat_routes).
https://bugzilla.gnome.org/show_bug.cgi?id=740064
Tests that use g_assert_expect_message() must initialize with
nmtst_init_assert_logging().
Otherwise, the caller can change the logging level via
NMTST_DEBUG=log-level=DEBUG,log-domains=DEFAULT
which breaks the assertions.
nmtst_init_assert_logging() allows the caller to turn of
checking of assertions via
NMTST_DEBUG=log-level=DEBUG,log-domains=DEFAULT,no-expect-message
Also, don't use g_message() in platform tests otherwise the test fail
because nmtst now sets g_log_set_always_fatal().
