When generating an NMConnection to match the current state of a
device, don't add its RA-provided and DHCP-provided routes to the
NMSettingIP4Config/NMSettingIP6Config, since those routes didn't come
from the connection profile before.
https://bugzilla.gnome.org/show_bug.cgi?id=729203
Instead of creating most routes with metric 0 and then fixing them
just before applying them, create the routes with the correct metric
in the first place (so that NMIP4Config and NMIP6Config don't have to
try to guess whether "metric 0" means "unset" or "actually metric 0").
NMIP4Config and NMIP6Config had methods to update an existing
NMSetting. However, the functions would really only work correctly if
the passed-in setting was empty.
Change them from "update_setting" to "create_setting", and have them
create the NMSetting themselves, and update NMDevice for that.
(If we need update_setting later, we can add it, after figuring out
exactly how it's actually supposed to work.)
When adding the same addresses from different sources, we want to
preserve the times with the later expiry . If the new address comes
from the kernel itself, we treat it specially and prefer the times
from other sources.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, when adding a gateway route to a destination within the
current subnets, it would be skipped because of the wrong assumption
that we already have a prefix route to that destination.
This assumption is wrong, because we want to reach the more specific
subnet via a gateway and not directly on the link.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Two issues:
1) routes added by external programs or by users with /sbin/ip should not
be modified, but NetworkManager was always changing those routes' metrics
to match the device priority. This caused the nm_platform_ipX_route_sync()
functions to remove the original, external route (due to mismatched metric)
and re-add the route with the NetworkManager specified metric. Fix that
by not touching routes which came from the kernel.
2) Static routes (from persistent connections) that specified a metric were
getting their metric overwritten with the NetworkManager device priority.
Stop doing that.
Since the platform no longer defaults the metric to 1024, callers of
nm_platform_ip4_route_add() (like NMPolicy's default route handling)
must do that themselves, if they desire this behavior.
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
Now that the objects get replaced when IP configuration changes
instead of being destroyed and a new one created, they need
PropertiesChanged signals.
(noticed as a result of auditing all exported D-Bus objects)
When a gateway is not in the prefix of any of the interface's IP addresses,
NetworkManager adds a static host route to the gateway through the
interface to ensure the gateway can be reached. That route will not
be part of the persistent connection (since it was added automatically)
but would normally be picked up by connection generation. This would
cause the generated connection not to match with the persistent
connection, because the persistent connection does not have the host
route. Ignore the gateway host route when capturing the interface's
existing IP configuration.
In the migration to NMPlatform, support for ptp/peer addresses was
accidentally dropped. This broke OpenVPN configurations using 'p2p'
topology, which send a different peer address than the local address
for tunX, plus the server may also push routes that use the peer
address as the next hop. NetworkManager was unable to add these
routes, because the kernel had no idea how to talk to the peer,
because the peer's address was not assigned to any interface or
reachable over any routes.
Partly based on a patch from Dan Williams.
There can be multiple default routes for an interface with different
metrics. Grab the gateway of the default route with the lowest
metric as the overall gateway of the IP config. Otherwise the rest
could get left in the config and applied at random times.
If the interface who's IP configuration is being captured has the default
route, then read DNS servers from resolv.conf into the NMIP[4|6]Config.
This allows NetworkManager to repopulate resolv.conf if anything changes.
For example, if the system does not define a persistent hostname, then
when a device which has generated a connection activates, a hostname
lookup will be performed. The results of that lookup may change resolv.conf,
and thus NetworkManager must rewrite resolv.conf. Without capturing
DNS information at startup when generating connections, an empty
resolv.conf would be written.
Follow the IP configuration the device currently has. For IPv6, this means
not using LINK_LOCAL if the interface doesn't have a LINK_LOCAL address.
Otherwise, NM assumes too much and may begin to activate an interface that
has no IP configuration, then time out and deactivate that device.
Also improve nm_ip4_config_dump to print all properties and make
use of nm_platform_*_to_string.
Also, ensure that never_default is set to gboolean 1 or 0.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
This new function copies the entire configuration of an existing
NMIP[46]Config object (src) and replaces the configuration in the destination
object (dst) in-place.
Signed-off-by: Thomas Haller <thaller@redhat.com>
libgsystem contains more than just the local allocation macros; in the
future we will likely want to make use of some of this such as the
structured logging support.
Before, when a route failed to be added, NM stopped adding further
routes. However, the activation still continued and the user was not
notified about the error.
Adding a route might fail for example if the gateway is not on one of
the subnets of the interface.
Now, a failure to add a route makes the activaion fail. If the
connection has autoconnect=yes, this might result in some unsuccessful
reconnection attempts.
In the future, we might want to distinguish between manually added routes
and routes from RA/DHCP. So that connecting to a wrongly configured DHCP
server still works for most parts.
https://bugzilla.redhat.com/show_bug.cgi?id=999544
Signed-off-by: Thomas Haller <thaller@redhat.com>
The fix in commit b5b43a6d65 missed the
release of the route instance (because nm_setting_ip4_config_add_route
does not take over the passed route but duplicates it).
So the orginal error was to free the route with the wrong deallocation
method gs_unref_object instead of nm_ip4_route_unref.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Most places except the tests don't want the default route when asking
the platform for all routes, so make that simpler by just adding a
parameter for including the default route or not.
Like IPv6, keep the DHCP/LLv4 config separate and combine it with the
NMSettingIP4Config to arrive at the final, combined IP4 config. This
brings the behavior in line with IPv6 code flow and will allow adding
the VPN routes config into the mix more easily.
Callers of these functions now only care whether two IP configs are
different and not what specific property changed, so we can simplify
this code down to a simple comparison for equality, based on the hashing
that's already done for the DNS manager.
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
Using the new gateway-ping-timeout property, send pings to the first
gateway address until it replies or the timeout is reached, to deal
with dumb hardware that indicates carrier on but doesn't actually
pass traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=702515
