update_connection() may be called during startup when the bus watch
hasn't notified yet the presence (or absence) of the teamd service on
the bus. Try to obtain a connection to the service in order to
retrieve the current configuration.
If the connection specifies an interface name, it should never attach to
a device of a different name even if the factory thinks the connection
is compatible with the device.
This fixes an issue that caused the inifniband connections to attach to
different devices or partitions.
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().
The hardware address of a VLAN must be kept aligned with the one of
its parent device, and we already used a signal in NMDeviceVlan to
catch changes in parent address and update the VLAN device
accordingly.
But this didn't work in all cases because the change might happen
after the VLAN gets created but before we register the signal, so it
is necessary to add further checks to enforce the alignment during the
device activation.
https://bugzilla.redhat.com/show_bug.cgi?id=1325752
Currently, NM_CP_SIGNAL_CONNECTION_UPDATED signal will be invoked on an
idle handler. I want to change that, so to be save, delay actions that
matter on an idle handler.
This allows tests to use these functions on a different platform instance
then on the singleton. The change makes the argument list longer, which is
unfortunate. On the other hand, it makes those functions more useful
in general.
You can't have it all.
Also, they now follow the pattern of most functions in NM where the type
is a singleton: you always pass the singleton to the function, although
in the usual case there is only one singleton instance. This allows to
use the function also on the non-singleton instance.
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.
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
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
When a value of a TYPE_BOTH option is read back from kernel it
contains both string and numeric values ("balance-rr 0"), so we must
chop off the number before adding the option to the setting. Also
change the default values of options to the string form so that the
option matching logic works.
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.
The fields in the neighbor variant should have a defined order.
Instead of sorting the hash table entries while constructing the
variant in lldp_neighbor_to_variant(), refactor the management of
the TLV attributes.
As we only support known attributes, we can
store them in an array at a known index instead of putting them
in a hash table.
An alternative would be to have explict fields for every known
attribute. That would be even more efficient, but requires more
work when adding new attributes.
We register the callback early on, so we get notified about
every single neighbor as they show up. No need to iterate over
them explicitly -- and probably, at that early state, there are
no neighbors yet.
The systemd event tells which neighbor changed. Make use
of this information and don't rebuild all the neighbors
all the time.
That means, we must also change our rate limiting. Instead of
rate limiting the processing of all neighbors, we process neighbors
right away but limit the notification that gobject property changed.
When we receive an update for a certain neighbor, the update
might be invalid and we want to reject it. However, we still
must create an invalid object to compare whether the update
causes a remove of a previously valid neighbor.
Let lldp_neighbor_new() create an instance as long as the
id fields are present.
