nm_vpn_connection_get_ip6_internal_gateway might return NULL. In this
case, we add a device route (to gateway '::') over the vpn.
Before, in such a case, NM crashed with SEGFAULT.
https://bugzilla.redhat.com/show_bug.cgi?id=1019021
Signed-off-by: Thomas Haller <thaller@redhat.com>
Only complete the setting name if it is at the very first
position after the connection.
e.g. complete the settings name in the case
$ nmcli connection modify em1 connec<TAB>
but not at
$ nmcli connection modify em1 connection.autoconnect <TAB>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Testcase:
* add 'NM_CONTROLLED=no' to /etc/sysconfig/network-scripts/ifcfg-ABC
* sudo nmcli con reload
* ... NM asserts ...
We need to ref() 'existing' connection before nm_settings_connection_signal_remove(),
because the function unref()s ithe connection via connection_removed_cb().
Backtrace:
...
#4 0x00007fbcf0ea0cba in g_assertion_message_expr (domain=domain@entry=0x0,
file=file@entry=0x7fbcf4e5805d "nm-dbus-manager.c", line=line@entry=848,
func=func@entry=0x7fbcf4e585e0 <__FUNCTION__.15088> "nm_dbus_manager_unregister_object", expr=expr@entry=0x7fbcf4e5820b "G_IS_OBJECT (object)")
at gtestutils.c:2293
#5 0x00007fbcf4de69d9 in nm_dbus_manager_unregister_object (
self=0x7fbcf6fdc9c0, object=0x7fbcf70235c0) at nm-dbus-manager.c:848
#6 0x00007fbcf4dd6a23 in nm_settings_connection_signal_remove (
self=<optimized out>) at settings/nm-settings-connection.c:1541
#7 0x00007fbce6fee884 in connection_new_or_changed (
self=self@entry=0x7fbcf7006f80,
path=path@entry=0x7fbcf70c3f80 "/etc/sysconfig/network-scripts/ifcfg-ABC",
existing=existing@entry=0x7fbcf70235c0,
out_old_path=out_old_path@entry=0x7fff2b7b8988) at plugin.c:327
#8 0x00007fbce6feeca2 in read_connections (plugin=0x7fbcf7006f80)
at plugin.c:453
#9 0x00007fbcf4dd8e98 in impl_settings_reload_connections (
self=0x7fbcf6fd98c0, context=0x7fbcf70bcb30) at settings/nm-settings.c:1262
...
nm_setting_bond_add_option returns TRUE or FALSE indicating, whether
the bond option was properly set. So, the API already kind of expects
invalid values, so there is no reason to warn about it.
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMSettingConnection was making sure that bond slaves didn't have an IP
configuration, but it should have been making that check for bridge
and team slaves too.
Several settings types' verify() functions need to find a particular
setting from the all_settings list that NMConnection passes them. Add
a convenience function for this.
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
Static IP addresses were only read from ifcfg-* file when IP method was
'manual' (BOOTPROTO=none|static). This was to match the legacy initscripts
behaviour. However, NetworkManager supports using additional static IPs in
addition to automatically obtained (DHCP, etc.) addresses. So we now read
static IPs even for automatic methods to be able to use this feature.
https://bugzilla.redhat.com/show_bug.cgi?id=998135
Plugins may have problems with preserving some properties on write/read cycle,
may add ipv{4,6} settings when they are not present in the connection, etc.
That makes local and remote connection differ.
So we copy remote connection into the local to get rid of such problems.
Note:
68f12b4e9c and
f03635e5ac
commits ensure that all connection (except slaves) have IPv{4,6} settings.
https://bugzilla.redhat.com/show_bug.cgi?id=997958
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>
nm_connection_provider_get_connections returns an internally kept
constant list to simplify handling for the users. Do not cache this
list in a static variable, instead put it in a private field.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a VPN had the default route, :primary-connection would become NULL,
which is exactly what it's not supposed to do. Fix it to have the
value it's supposed to.
https://bugzilla.gnome.org/show_bug.cgi?id=710207
The internal VLAN flags were translated into the kernel VLAN flags but
finally the internal ones were passed to the kernel instead.
Reported-by: Julien Nabet <serval2412@yahoo.fr>
Before, you had to select at compile time to run BlueZ4 or BlueZ5.
Now, both versions are enabled together and NM detects the actual
version at runtime.
The configure option --enable-bluez4 got removed.
The advantage is now, that you can switch between the two versions of
BlueZ without rebuilding NetworkManager. Note however, that you still
must restart NetworkManager, because once a version is detected, it will
not switch again as long as the process runs.
Another advantage is that before not all code was build, and you had
to build two configurations for testing.
https://bugzilla.gnome.org/show_bug.cgi?id=709412
Signed-off-by: Thomas Haller <thaller@redhat.com>
Fix several issues with emitting the BDADDR_ADDED/BDADDR_REMOVED
signals:
- when removing a device, the handlers were never disconnected from
the device's notify::usable and initialized signals.
- ensure that the signals BDADDR_ADDED/BDADDR_REMOVED only get emitted
in a consistent way (toggeling). Before, there was a bug, that the
signal BDADDR_REMOVED was emitted for devices that were never added
and never usable.
Co-Authored-By: Dan Williams <dcbw@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Refactor nm-bluez-device.c to use GDBus both to connect to
BlueZ 4 and BlueZ 4.
Also remove the unused property RSSI.
Also prefix every logline with the dbus path of the device.
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMBluezManager is now a proxy and only delegates to either
NMBluez4Manager or NMBluez5Manager. It detects the running BlueZ
version at runtime, and once it decides for one version, it cannot be
changed anymore as long NetworkManager is running.
This means, when switching from BlueZ4 to BlueZ5 or vice versa you have
to restart NetworkManager. This should be acceptable, because it is
not a common use case (most systems won't have both versions installed
anyway) and it greatly simplifies implementation.
Also note that NMBluez4Manager and NMBluez5Manager do not implement a
common interface. NMBluezManager delegates to the correct manager.
Having them share an common interface or base class would not simplify
the code, because NMBluezManager not only delegates, but it also acts as
a proxy until it is decided which BlueZ version is running. So, this
proxy-like behaviour would still be needed. The alternative would be to
merge the functionality of all three NMBluez*Manager classes into one.
This also removes the --enable-bluez4 configure switch, because both
versions are now always enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=709412
Signed-off-by: Thomas Haller <thaller@redhat.com>
