One setting may contain a superset or subset of the another. Be sure not
to ignore the presence of extra secret properties.
(cherry picked from commit 16f8651908)
They're triggered by the prototypes in header file inclusion, even
though no routines or variables that use the type are actually used.
(cherry picked from commit 685cb5c88b)
In the past we had NMDefaultRouteManager which would coordinate adding
the default-route with identical metrics. That especially happened, when
activating two devices of the same type, without explicitly specifying
ipv4.route-metric. For example, with ethernet devices, the routes on
both interfaces would get a metric of 100.
Coordinating routes was especially necessary, because we added
routes with NLM_F_EXCL flag, akin to `ip route replace`. We not
only had to avoid that activating two devices in NetworkManager would
result in a fight over the default-route, but more importently
to preserve externally added default-routes on unmanaged interfaces.
NMDefaultRouteManager would ensure that in case of duplicate
metrics, that the device that activated first would keep the
best default-route. It would do so by bumping the metric
of the second device to find a unused metric. The bumping itself
was not very important -- MDefaultRouteManager could also just not
configure any default-routes that show up as second, the result
would be quite similar. More important was to keep the best
default-route on the first activating device until the device
deactivates or a device activates that really has a better
default-route..
Likewise, NMRouteManager would globally manage non-default-routes.
It would not do any bumping of metrics, but it would also ensure that the routes
of the device that activates first are not overwritten by a device activating
later.
However, the `ip route replace` approach has downsides, especially
that it messes with routes on other interfaces, interfaces that are
possibly not managed by NetworkManager. Another downside is, that
binding a socket to an interface might not result in correct
routes, because the route might just not be there (in case of
NMRouteManager, which wouldn't configure duplicate routes by bumping
their metric).
Since commit 77ec302714 we would no longer
use NLM_F_EXCL, but add routes akin to `ip route append`. When
activating for example two ethernet devices with no explict route
metric configuration, there are two routes like
default via 10.16.122.254 dev eth0 proto dhcp metric 100
default via 192.168.100.1 dev eth1 proto dhcp metric 100
This does not only affect default routes. In case of a multi-homing
setup you'd get
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100
but it's visible the most for default-routes.
Note that we would append the routes that are activated later, as the order
of `ip route show` confirms. One might hence expect, that kernel selects
a route based on the order in the routing tables. However, that isn't
the case, and activating the second interface will non-deterministically
re-route traffic via the new interface. That will interfere badly with
with NAT, stateful firewalls, and existing connections (like TCP).
The solution is to have NMManager keep a global index of the default route-metrics
currently in use. So, instead of determining the default-route metric based solely
on the device-type, we now in addition generate default metrics that do not
overlap. For example, if you activate eth0 first, it gets route-metric 100,
and if you then activate eth1, it gets 101. Note that if you deactivate
and re-activate eth0, then it will get route-metric 102, because the
best route should stick on eth1 (which reserves the range 100 to 101).
Note that when a connection explititly selects a particular metric, then that
choice is honored (contrary to NMDefaultRouteManager which was more concerned
with avoiding conflicts, then keeping the exact metric).
https://bugzilla.redhat.com/show_bug.cgi?id=1505893
(cherry picked from commit 6a32c64d8f)
NMManager will need to know the state of all device at once.
Hence, load it once and cache it in NMConfig.
Note that this wastes a bit of memory in the order of
O(number-of-interfaces). But each device state entry is
rather small, and we always consume memory in the order
of O(number-of-interfaces).
(cherry picked from commit ea08df925f)
binary-search can find an index of a matching entry in a sorted
list. However, if the list contains multiple entries that compare
equal, it can be interesting to find the first/last entry. For example,
if you want to append new items after the last.
Extend binary search to optionally continue the binary search
to determine the range that compares equal.
(cherry picked from commit d83eee5d57)
Probably not critical, because it will still include
the terminating NULL, and just continue to fill the
temporary buffer with static addresses.
Found by coverity.
Fixes: bfb9fd0d2f
(cherry picked from commit c274b565a6)
@kind might be NULL. There are 3 forms of the hash-update functions for
string: str(), str0(), and strarr().
- str0() is when the string might be NULL.
- str() does not allow the string to be NULL
- strarr() is like str(), except it adds a G_STATIC_ASSERT()
that the argument is a C array.
The reason why a difference between str() and str0() exists, is
because str0() hashes NULL different from a "" or any other string.
This has an overhead, because it effectively must hash another bit
of information that tells whether a string was passed or not.
The reason is, that hashing a tupple of two strings should always
yield a different hash value, even for "aa",""; "a","a"; "","aa",
where naive concatentation would yield identical hash values in all
three cases.
Fixes: e75fc8279b
(cherry picked from commit 27e8fffdb8)
It's not critical, because at worst we get a false-positive that
something changed.
Found by coverity.
Fixes: 4e7b05de79
(cherry picked from commit fbc6008260)
The idea is
tfilter.<parent>=[handle <handle>] <tfilter> [<options>] [action [<action options>...]]
What works now:
[tc]
qdisc.root=handle 1234: fq_codel
qdisc.ffff:fff1=ingress
tfilter.1234:=matchall action drop
tfilter.ffff:=matchall action simple sdata Hello
(cherry picked from commit 2e8fc6947d)
Printing a g_warning() from the library is not helpful.
Client-side, libnm should support newer server versions and changing
formats. To support forward-compatibility, it should parse the received
GVariant best-effort like, without complaining.
Server-side, libnm-core should return errors when receiving invalid
configuration. It must not maintain forward-compatibility, only
backward-compatibility -- which is implemented by handling old
and newer formats. But never should server allow a configuration
that is invalid.
Currently, the libnm API cannot yet fail at this point. Hence,
it cannot return an error. It would need a strict and relaxed
parsing mode. Until that exists, just comment out the warnings.
(cherry picked from commit 7cd2b6178d)
The actions are not too useful my themselves, but it will be possible to
embed them into traffic filters in subsequent commits.
(cherry picked from commit 7c8ce778fb)
The format for qdiscs is
qdisc.<parent>=[handle <handle>] <qdisc> [<options>...]
E.g.:
[tc]
qdisc.root=fq_codel handle de4d:
qdisc.ffff:fff1=ingress
That is pretty much what is supported at this point.
(cherry picked from commit 9d0eeb30b6)
