Create a NMRouteManager singleton.
Refactor, no functional changes apart from change of log domain from
LOGD_PLATFORM to LOGD_CORE.
Subsequent commit will keep track of the conflicting routes, avoid overwriting
older ones with newer ones and apply the new ones when the old ones go away.
(cherry picked from commit 874e4a7595)
Previously for assumed connections we would never configure a default route.
That has serious problems for example in the following two scenarios:
- the default-route might have a limited lifetime from a previous
SLAAC/accept_ra setting. In this case, once we assume the connection
we must also ensure that we extend the lifetime of the default
route.
- the gateway could be received via DHCP/RA and it might change.
If we ignore default-routes for assumed connection we miss that
change.
The problem is that the notion of "assumed connection" wrongly combines
two conflicting goals (related bug bgo#746440):
a) have an external device that is entirely unmanged by NM.
b) do a seamless takeover of a previously managed connection at start,
but still fully manage.
This patch changes the handling of default-routes towards meaning b).
https://bugzilla.redhat.com/show_bug.cgi?id=1224291
(cherry picked from commit d51975ed92)
Since da708059da, we would pickup the
default-route as configured externally, except at those moments when
NM re-applys the IP configuration of the interface, such as during a
DHCP lease.
That allows the user to add/remove the default-route externally (iproute).
But still, at random times (DHCP lease), we will revert those external
changes.
Extend this, that if the connection is explicitly configured as
'never-default=yes', that it tells NM not to interfere with externally
added default-routes on this device. That means, NM will only remove
any preexisting default-routes when configuring the device a first
time.
On any later attempts, NM will assume whatever is configured there.
That makes sense because the user indicated not wanting NM to
manage a default-route on that device, so if something externally
added a default-route, assume that is what the user wants.
This only affects non-assumed connections, with 'never-default=yes'.
https://bugzilla.redhat.com/show_bug.cgi?id=1205405
(cherry picked from commit 98e50e358b)
When a connection had static IP addresses, an early event
from plaform would clear them from priv->con_ip4_config.
Fix that, by don't initializing priv->con_ip4_config
before we commit the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=749052
Fixes: 557667df12
(cherry picked from commit 843205521f)
It would subtract the configuration from device confguration that's not yet
applied. This a the race where the loose the address while activating a
connection that has both IPv6 and IPv4 configuration.
Fixes: 557667df12https://bugzilla.gnome.org/show_bug.cgi?id=746066
(cherry picked from commit 2e99ddb7a7)
Even more eagerly pickup external default routes from the device.
For assumed devices we already picked up the default route.
(a) For assumed devices we already did not enforce the default route at all.
Instead it was always picked up by from the actualy system
configuration. Note that this is the case for assumed-generated
connections and for assuming existing connections.
That means that when NM assumes a connection at startup, it will never
actively manage the default route on that interface. It will only react
on what is present.
(b) For managed devices that have by configuration no default route, still pick up
the default route. That means, that even a device that is managed and
never-default=yes, can have the default route -- if configured externally.
(c) Only during a commit phase (i.e. when we have new configuraiton to be
applied), we enforce the default route or its absence.
(d) During any IP change event from platform, we again pickup whatever
is present. That means if you remove the default route from a managed
interface, NM will not re-add it until anything triggers (c).
This also means, that during the commit phase, we add default routes as
'synced' to the default-route-manager, but the following event from platform,
will change the route entry immediately to 'non-synced'. That is
expected and correct.
(cherry picked from commit da708059da)
When receiving IP changes via platform event, remove all missing
addresses and routes from our internal configurations (such as
wwan, vpn, dhcp).
The effect is that on the next commit, those addresses and routes will
not be re-added as they were explicitly removed by the user.
However on a new DHCP lease or similar events, the addresses will
be added anew.
Another important improvement is that the NMIPxConfig of the active
device reflects when addresses or routes get removed externally. Before
we would continue to expose those entires although they were not
actually configured on the device.
https://bugzilla.gnome.org/show_bug.cgi?id=740443
(cherry picked from commit 557667df12)
In the IPv4 case, we check whether we have a direct route to the gateway
also by looking at the configured addresses/subnets. That is correct,
because every IPv4 address also implies a subnet route.
For IPv6, we explicitly add all subnet routes manually (noprefixroute),
hence, we have a direct route exactly if we have it in our list.
Regardless of the configured IPv6 prefixes.
(cherry picked from commit 2c06449085)
Factor out code of the nm_ip4_config_subtract() and
nm_ip6_config_subtract() functions. The code can be reused in the
following commit.
(cherry picked from commit 92d800b2e3)
It's not uncommon to lookup a platform parameter with invalid
ifindex or ifname. Be more resilient and just return "no link found".
Fixes: e8e455817b
(cherry picked from commit 0a38352470)
Change nm_platform_link_get() to return the cached NMPlatformLink
instance. Now what all our implementations (fake and linux) have such a
cache internal object, let's just expose it directly.
Note that the lifetime of the exposed link object is possibly quite
short. A caller must copy the returned value if he intends to preserve
it for later.
Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address()
to return the instance.
Certain functions, such as nm_platform_link_get_name(),
nm_platform_link_get_ifindex(), etc. are solely implemented based
on looking at the returned NMPlatformLink object. No longer implement
them as virtual functions but instead implement them in the base class
(nm-platform.c).
This removes code and eliminates the redundancy of the exposed
NMPlatformLink instance and the nm_platform_link_get_*() accessors.
Thereby also fix a bug in NMFakePlatform that tracked the link address
in a separate "address" field, instead of using "link.addr". That was
a case where the redundancy actually led to a bug in fake platform.
Also remove some stub implementations in NMFakePlatform that just
bail out. Instead allow for a missing virtual functions and perform
the "default" action in the accessor.
An example for that is nm_platform_link_get_permanent_address().
(cherry picked from commit e8e455817b)
We must check if a conflicting route/address is configured on
*any* interface, not only on the target ifindex.
This at least restores the previous behavior. Note that this whole
check_reinstall_device_route() still has problems and it might
be better to move it all to NMRouteManager.
Fixes: 470bcefa5f
(cherry picked from commit 1bfade833a)
After doing all the refactoring, rename the ObjectType enum to NMPObjectType.
I didn't do this earlier to avoid problems with rebasing. But since I will
backport the platform changes to nm-1-0, this is the right time to get
the name right.
(cherry picked from commit 518cf76de7)
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
In C function() and function(void) are two different prototypes (as opposed to
C++).
function() accepts an arbitrary number of arguments
function(void) accepts zero arguments
(cherry picked from commit 2dc27a99d7)
After refactoring platform, nm_platform_ipx_route_get_all() and
nm_platform_ipx_address_get_all() was broken for calling with a
non-posititive ifindex (which has the meaning: ignore ifindex).
While fixing that, also refactor the NMPCacheIdType so that it matches
better the supported id-types.
Fixes: 470bcefa5f
(cherry picked from commit 8f9dac01ac)
When inside a state-change, we set for example the device up.
This triggers a link-changed event, which then causes further
state-changes of the devices.
A state-change in process of a device is not reentrant, so we must
delay the handling of the link-changed event.
(cherry picked from commit 04caae735f)
For NMPlatform instances we had an error reporting mechanism
which stores the last error reason in a private field. Later we
would check it via nm_platform_get_error().
Remove this. It was not used much, and it is not a great way
to report errors.
One problem is that at the point where the error happens, you don't
know whether anybody cares about an error code. So, you add code to set
the error reason because somebody *might* need it (but in realitiy, almost
no caller cares).
Also, we tested this functionality which is hardly used in non-testing code.
While this was a burden to maintain in the tests, it was likely still buggy
because there were no real use-cases, beside the tests.
Then, sometimes platform functions call each other which might overwrite the
error reason. So, every function must be cautious to preserve/set
the error reason according to it's own meaning. This can involve storing
the error code, calling another function, and restoring it afterwards.
This is harder to get right compared to a "return-error-code" pattern, where
every function manages its error code independently.
It is better to return the error reason whenever due. For that we already
have our common glib patterns
(1) gboolean fcn (...);
(2) gboolean fcn (..., GError **error);
In few cases, we need more details then a #gboolean, but don't want
to bother constructing a #GError. Then we should do instead:
(3) NMPlatformError fcn (...);
(cherry picked from commit 68a4ffb4e2)
Unconditionally log a warning if the function fails.
We are about to drop nm_platform_get_error(), it's anyway unclear
why we don't want to log a warning about non-existing interface.
(cherry picked from commit 8334171a4e)
Later remove nm_platform_get_error() and signal errors via return
error codes.
Also, fix nm_platform_infiniband_partition_add() and
nm_platform_vlan_add() to check the type of the existing link
and fail with WRONG_TYPE otherwise.
(cherry picked from commit d7fe907c32)
- rename "NONE" to "SUCCESS", what it really is.
- change the to-string result not to contain spaces
and being closer the name of the enum value.
- add new error reasons "UNSPECIFIED" and "BUG".
- remove the code comments around the enum definition.
They add no further description about why this error
happens and only paraphrase the name of the enum.
- reserve negative integers for 'errno'. This is neat
because if we get a system error we can pass on the
underlying errno as cause.
(cherry picked from commit f7fb68755c)
Don't expose @obj directly but clone the public fields. A signal
handler might call back into NMPlatform which could invalidate (or modify)
@obj.
(cherry picked from commit e7ee2fc139)
After hiding the udi field, there are no more users of NMRefString.
Remove the code by explitly reverting the patch so that in case of a future
need, we can find and resurrect NMRefString.
This reverts commit d0e2937006.
(cherry picked from commit 3359dddd2e)
The @udi field is not a static string, so any user of a NMPlatformLink
instance must make sure not to use the field beyond the lifetime of the
NMPlatformLink instance.
As we pass on the platform link instance during platform changed events,
this is hard to ensure for the subscriber of the signal -- because a
call back into platform could invalidate/modify the object.
Just not expose this field as part of the link instance. The few callers
who actually needed it should instead call nm_platform_get_uid(). With
that, the lifetime of the returned 'const char *' pointer is clearly
defined.
(cherry picked from commit 1b2b988ea9)
Use the event socket to request object via NLM_F_DUMP.
No longer use 'priv->nlh' socket to fetch objects.
Instead fetch them via the priv->nlh_event socket that also
provides asynchronous events when objects change.
That way, the events are in sync with our explicit requests
and we can directly use the events. Previously, the events were
only used to indicate that a refetch must happen, so that every
event triggered a complete dump of all addresses/routes.
We still use 'priv->nlh' to make synchronous requests such as
adding/changing/deleting objects. That means, after we send a
request, we must make sure that the result manifested itself
at 'nlh_event' socket and the platform cache.
That's why we sometimes still must force a dump to sync changes.
That could be improved by using only one netlink socket so that
we would wait for the ACK of our request.
While not yet perfect, this already significantly reduces the number of
fetches. Additionally, before, whenever requesting a dump of addresses
or routes (which we did much more often, search for "get_kernel_object for type"
log lines), we always dumped IPv4 and IPv6 together. Now only request
the addr-family in question.
https://bugzilla.gnome.org/show_bug.cgi?id=747985https://bugzilla.redhat.com/show_bug.cgi?id=1211133
(cherry picked from commit 051cf8bbde)
