When the IP status is IP_DONE and a DHCP transaction succeeds the
'dhcp4' and 'dhcp6' pending actions must be removed. Without this, a
temporary link loss just after the activation would cause a DHCP
restart and those actions would remain set, blocking the startup.
https://bugzilla.redhat.com/show_bug.cgi?id=1330893
Once we start with dispose, we certainly don't want to process any platform
events for the device anymore.
Previously, we disconnect those handlers only later during dispose, so it's
not clear that we would not receive a device_ipx_changed signal after _cleanup_generic_pre().
Fix this possible (or actual) bug.
Since commit a47c13a7a2, update_ip4_config() re-schedules
itself in case activate_stage5_ip4_config_commit is pending. Thus, there is no need to
cancel any queued queued_ip4_config_id.
Also as that does not properly fix the issue unlike a47c13a7a.
update_ip4_config() and update_ip6_config() are called from nm_device_capture_initial_config().
At that point, we don't expect any activation-source scheduled, thus the "if" should not
not be hit anyway.
So, this patch should actually make no difference, but it seems clearer
to me. Also, because it would be a bug to re-schedule the idle handler
that is already pending, but from inspecting nm_device_capture_initial_config()
it is not immediately clear that this cannot be the case.
Make DHCPv6 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Make DHCPv4 more robust WRT temporary failures of servers by retrying
DHCP for a predefined number of times at regular intervals when the
lease expires.
https://bugzilla.gnome.org/show_bug.cgi?id=741347
Introduce the nm_device_ip_method_failed() function to check if the
failure of an IP method should cause the activation to fail, and use
it where appropriate.
http://bugzilla.gnome.org/show_bug.cgi?id=741347
When a new dynamic configuration is received, it is stored in a member
of private structure (e.g. @dhcp6_ip6_config) and a commit is
scheduled. Before the commit is executed, an update_ipx_config() could
be called and it would change the configuration before it is
committed.
This race condition causes failures in assigning the addresses
received through DHCPv6 when the internal client is used (but
potentially other clients and methods are affected).
To fix it, postpone updates of IP configurations when a commit is
already pending.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
The infiniband drivers don't implement the rtnetlink link deletions.
Therefore we unrealize the NMDevice instance but the backing resources
stay around, preventing us from ever realizing the device again.
When we want to preserve the default-route on cleanup, we must first
set it to assumed, before clearing it. Otherwise, NMDefaultRouteManager's
update() will delete the default route.
This is the oposite of the deconfigure case, where we first set it to
!has && !assumed, to force the route-manager to delete the route.
Add a function _update_default_route() to set the default_route
flags and call update() in one step.
Also, if there are no changes, skip the call to NMDefaultRouteManager's
update().
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.
If the manager removes the device, the IP config objects must
be cleared. The reason is that NMPolicy registers to the IP config
changed signal and passes these object on to NMDnsManager.
If the INTERNAL_DEVICE_REMOVED signal is emited with IP configuration
object pending, those objects will be leaked.
This partly redoes commit f72816bf10,
which was reverted.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=764483
Software devices created by NM should be kept up when quitting so that
they can be assumed upon restart. But now we consider devices created
by NM (those with the @is_nm_owned flag) not capable of assuming
connections and therefore we tear them down and deconfigure when
quitting.
Change this and ignore @is_nm_owned when deciding if a device can be
re-assumed.
First let the device know it's being removed soon so that it has a
chance to clean up the IP configuration early.
If the manager removes the device fist, the policy never learns of
config removal and doesn't unhook it from the DNS manager resulting in a
IPConfig leak and possible wrong DNS configuration in effect.
Also adjust the route manager to skip over devices without IP
configuration when determining the best connection; it is perhaps
just due to being removed.
https://bugzilla.gnome.org/show_bug.cgi?id=764483
This makes sure that devices like bond get their dhcp renewed
[thaller@redhat.com: original patch modified to rename
now-public function update_dynamic_ip_setup()]
https://bugzilla.gnome.org/show_bug.cgi?id=764398
There is no excuse for clients to send connections to NetworkManager
that have invalid/unknown fields. Just reject them.
As Reapply() is new API in nm-1-1, there is no problem with backward
compatibility.
If it's traversing from unavailable to disconnected (e.g. realizing
of the device was delayed because it was awaiting the parent connection),
then we just want to progress the activation.
We'll need to share the best conneciton logic and it's the only caller
of nm_device_get_available_connections(). Let's just move it all to
NMDevice and provide the best connection from there instead.
No point ins storing "TRUE" as value in the @shared_ips hash
table. That forces glib to allocate a separate storage for the
value. Just use g_hash_table_add() instead.
