Support new bonding options and set them carefully. The options cannot
be set arbitrarily because they interfere with each other.
This commit is forward-ported from rhel-6.5, see patch
rh901662-bond-more-options.patch, originally written by Dan Williams.
https://bugzilla.redhat.com/show_bug.cgi?id=901662https://bugzilla.redhat.com/show_bug.cgi?id=905532
Co-Authored-By: Dan Williams <dcbw@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
When an interface is manually disconnected NM remembers that, and prevents
automatic activation of the device.
However, software devices are removed when they are disconnected, and thus
the state of the device is lost. We need to track autoconnect outside the
device - hash table of interface names not allowed to activate automatically.
Without that the device would be auto-activated again and again, even if
explicitly disconnected.
Test case:
$ nmcli con add type bond ifname bb con-name bb-con
$ nmcli con add type bond-slave ifname em1 con-name b1-con master bb
$ nmcli dev disconnect bb
https://bugzilla.redhat.com/show_bug.cgi?id=1005913
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.
Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
To present a consistent API to clients, the IP-related properties
are only valid when the device has finished IP configuration. But
they are set before that happens, and their change notifications
were emitted before the IP configuration was considered valid.
Re-emit the change notifications when the device enters the IP_CHECK
state (and thus has IP configuration) and also when the device
deactivates to enusre clients have up-to-date IP-related property
information.
For the changes to has_ip_config(), the priv->ipX_state checks are
not necessary since the device will have valid IP configuration
when it enters the IP_CHECK state. The other checks can be
consolidated into a single statement.
Acked-by: Dan Winship
If the user disabled IPv6 support in the kernel with "ipv6.disable=1" on the
kernel boot line, then any attempts to open IPv6 sockets (which libndp does)
will fail. This failed the entire connection, even if IPv6's "may-fail"
property was TRUE. Instead, just fail IPv6 and allow IPv4 to proceed. If
IPv4 fails or is disabled, then other logic will fail the entire connection.
g_child_watch_add only emits one signal and gets automatically
removed from the source. No need for double removal, so unset
teamd_process_watch before calling teamd_cleanup.
Signed-off-by: Thomas Haller <thaller@redhat.com>
g_bus_watch_name immediatly emits a vanished signal, if the name does not exist
at the begining. So the first signal, does not indicate an actual change of
state and must be ignored.
Signed-off-by: Thomas Haller <thaller@redhat.com>
teamd was being watched using g_bus_watch_name(). But when the NM team device
was destroyed NM tried to remove the watcher with g_source_remove() instead of
g_bus_unwatch_name(). Thus the watcher was not removed and
teamd_dbus_appeared() was called on disposed device.
https://bugzilla.redhat.com/show_bug.cgi?id=1013593#c28
Signed-off-by: Thomas Haller <thaller@redhat.com>
The variable teamd_on_dbus in nm-device-team was never set to TRUE.
Remove it. Also, before teamd_dbus_vanished did never cleanup anything.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The assertion that priv->teamd_pid is set does not hold.
For example, if no teamd binary can be found, "Stage 1 of 5 (Device
Prepare)" fails with "Activation (nm-team) to start teamd: not found".
This causes the device state to become "failed" and later
"disconnected", which in turn calls teamd_stop without a valid teamd_pid
set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMDeviceTeam dispose() did not chain up to parent dispose(). This prevented
parent dispose() to be called (only finalize()) and thus link_changed_cb()
and device_ip_changed() handlers were not disconnected. Later these handlers
were called on invalid device resulting in a crash.
https://bugzilla.redhat.com/show_bug.cgi?id=1013593
Don't unconditionally call disconnect during device deactivation, since
the device also gets deactivated in the UNAVAILABLE -> DISCONNECTED
state change, long before any Bluetooth connection has been made.
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>
IPoIB "hardware addresses" are only partly based on the hardware, and
partly based on the InfiniBand configuration. So when checking if a
configuration matches a device, we should only match the fixed part.
If there are no specs, then the device can't match, so don't call the
virtual method (which might do work like building comparison strings
even when the list is empty).
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
Rather than having NMManager know how to parse various settings to
create each kind of software device, add a _new_for_connection()
constructor to each of them and let them call NMPlatform to create the
device correctly themselves.
Rather than setting the VLAN maps when the device is created, set them
at activation time, which is more in line with how other device types
work.
Like the old code, this doesn't attempt to reset any existing
ingress/egress mappings on the device.
Cache externally added IP details and represent them via the D-Bus
interface, and also merge them into the final device config to ensure
they aren't lost if DHCP renews or RA changes occur.
Add a flag to indicate that the device is owned by NM.
This is interesting for software/virtual devices, that were created by
NM and should be deleted when the interface gets deactivated.
This flag is not implemented as a glib property.
Maybe this flag can be consolidated with the managed flag. For now it is
unclear how to do it, so add this flag. It should be easy later to
replace it again.
https://bugzilla.gnome.org/show_bug.cgi?id=695705https://bugzilla.redhat.com/show_bug.cgi?id=953300
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a glib assertion.
Backtrace:
#0 0x00007f139ab08e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f139ab08ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003f9aa3151a in g_type_check_instance () from /lib64/libgobject-2.0.so.0
#3 0x0000003f9aa272d4 in g_signal_handlers_disconnect_matched () from /lib64/libgobject-2.0.so.0
#4 0x0000000000495b7d in supplicant_interface_release (self=0xc58040) at devices/nm-device-wifi.c:423
#5 0x0000000000498a28 in dispose (object=0xc58040) at devices/nm-device-wifi.c:3525
#6 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#7 0x000000000047699a in remove_device (manager=manager@entry=0xc09050, device=0xc58040, quitting=quitting@entry=1) at nm-manager.c:748
#8 0x0000000000478a84 in dispose (object=0xc09050) at nm-manager.c:4558
#9 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#10 0x0000000000428cc0 in main (argc=1, argv=0x7fffc0948c98) at main.c:626
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.
These devices don't have a platform device at creation time, thus
is_software wasn't getting set properly. Move the is_software
decision to constructed() because by this point, the iface and
ifindex (if present) will be known for all cases and thus we can
figure out if it's a software device or not in one place.
