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.
(cherry picked from commit 332994f1b1)
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.
(cherry picked from commit 4697376f99)
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().
(cherry picked from commit b2f794fe1e)
We must preserve the default-route on shutdown.
Thus it must first be announced as "assumed", and only removed
in a second step.
Fixes: 9498ea507e
(cherry picked from commit 2079f8361c)
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
(cherry picked from commit a032ce72ea)
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.
(cherry picked from commit c4151ebb5b)
On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
(cherry picked from commit 44768f0311)
On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
(cherry picked from commit 14ee5dd2f8)
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.
Instead of replacing the whole hash with a new one (and all new by a new one,
LldpNeighbor instances), update the existing hash.
One point of this is that our process-all function requires less
comparisons and avoids duplicate work right earlier. E.g. if a neighbor
didn't change, we don't have to put it into a hash to compare later for
equality.
But more importantly, we preserve our LldpNeighbor instance instead
of recreating them all the time. Later, the LldpNeighbor will cache
the GVariant.
Otherwise the connection wouldn't verify:
<error> [1458066126.2270] device (eth10): Generated connection does not verify:
connection.type: property type should be set to '802-3-ethernet'
<debug> [1458066126.2271] manager: (eth10): can't assume; no connection
(cherry picked from commit 4b71939e9ac3df93bfe72af0eac42b4ebaf94e15)
The prune list is for elements that must be deleted from the list of
available connections. So, when processing all the existing
connections an element must be deleted from the prune list iff it's
available.
Fixes: 8b2abe0e2chttps://bugzilla.redhat.com/show_bug.cgi?id=1316488
Make the test helper independent from the platform singleton instance.
That way, we can also use them for other platform instances (e.g. in a
different namespace).
