In the specific case that triggered this bug, both eth0 and eth0.123
existed and were configured before NM started, and a valid saved connection
existed for eth0.123. eth0 was ordered before eth0.123 in the Platform's
link list. When the end of add_devices() was reached for eth0 and
system_create_virtual_devices() was called, NM created an NMDevice for
the pre-existing eth0.123 link due to the saved connection, and
ignored the existing configuration because system_create_virtual_device()
re-calls add_device() with generate_con = FALSE.
Instead, we should allow system_create_virtual_device() to call add_device()
with generate_con = TRUE if the interface existed before NM created it. We
only want to skip connection assumption if the device was actually just
created by NM, in which case it cannot have any configuration to assume.
This didn't previously matter because BT/WWAN/WiFi/ADSL can't easily
assume existing connections due to the external helpers involved, but
when we converted Team support to a plugin we now want to allow this.
For NMDeviceWifi and NMDeviceWimax, the printf format string for
nm_utils_complete_generic() was created based on ssid/nsp. Since
these input strings are untrusted, this is a serious bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The fact that NMRemoteConnection has to be an NMConnection and
therefore can't be an NMObject means that it needs to reimplement bits
of NMObject functionality (and likewise NMObject needs some special
magic to deal with it). Likewise, we will need a daemon-side
equivalent of NMObject as part of the gdbus port, and we would want
NMSettingsConnection to be able to inherit from this as well.
Solve this problem by making NMConnection into an interface, and
having NMRemoteConnection and NMSettingsConnection implement it. (We
use some hacks to keep the GHashTable of NMSettings objects inside
nm-connection.c rather than having to be implemented by the
implementations.)
Since NMConnection is no longer an instantiable type, this adds
NMSimpleConnection to replace the various non-D-Bus-based uses of
NMConnection throughout the code. nm_connection_new() becomes
nm_simple_connection_new(), nm_connection_new_from_hash() becomes
nm_simple_connection_new_from_hash(), and nm_connection_duplicate()
becomes nm_simple_connection_new_clone().
Now that we have nm_utils_hwaddr_matches() for comparing addresses
(even when one is a string and the other binary), there are now places
where it's more convenient to store hardware addresses as strings
rather than binary, since we want them in string form for most
non-comparison purposes. So update for that.
In particular, this also changes nm_device_get_hw_address() to return
a string.
Also, simplify the update_permanent_hw_address() implementations by
assuming that they will only be called once. (Since they will.)
Add nm_utils_hwaddr_matches(), for comparing hardware addresses for
equality, allowing either binary or ASCII hardware addresses to be
passed, and handling the special rules for InfiniBand hardware
addresses automatically. Update code to use it.
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
GLib/Gtk have mostly settled on the convention that two-letter
acronyms in type names remain all-caps (eg, "IO"), but longer acronyms
become initial-caps-only (eg, "Tcp").
NM was inconsistent, with most long acronyms using initial caps only
(Adsl, Cdma, Dcb, Gsm, Olpc, Vlan), but others using all caps (DHCP,
PPP, PPPOE, VPN). Fix libnm and src/ to use initial-caps only for all
three-or-more-letter-long acronyms (and update nmcli and nmtui for the
libnm changes).
Child devices shouldn't be exposed as real NMDevices (yet) since the
configuration and life cycle is controlled by the parent. We already
do this if the ip_iface is known when the child device is added, but
PPP and other transient interfaces often show up just before we know
the parent's ip_iface.
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
The interface is owned by the parent NMDeviceBt and is not independently
usable. If not ignored, NM tries to assume a connection on the bnep
interface and messes the Bluetooth connection up.
Previous commit 38a83e15a2 moves the
team device to a plugin. If the plugin is not available, we should
log an information that we create a generic device instead.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Refactor the loading of device plugins by creating the list of
module filenames in a separate function.
Thereby also check for file permissions (must be only modifiable by root)
and sort the files by last file modification time. This has the advantage,
that if several plugins provide the same device type, that we (deterministically)
prefer the most recent one.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
NM fails to activate a slave if the master device already exists
but has not active connection.
One way to reproduce, create a bond master/slave configuration and
ensure that the master device exists (e.g. by activating the bond, and
killing NM without taking down the device, or externally via `ip link add`).
If you try to activate the slave it will fail with the following message
(in nmcli):
"Error: Connection activation failed: The active connection on MASTER is not a valid master for 'SLAVE'"
although MASTER is not active.
This also triggers the following assertion:
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000000047646a in is_compatible_with_slave (master=0x0, slave=slave@entry=0xc4aa60) at nm-manager.c:2193
#3 0x000000000047e289 in ensure_master_active_connection (self=self@entry=0xc8d150, subject=0x7f23b80059e0, connection=connection@entry=0xc4aa60, device=device@entry=0xcac380, master_connection=master_connection@entry=0x0,
master_device=master_device@entry=0xc9e800, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2395
#4 0x000000000047eb4a in _internal_activate_device (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2665
#5 0x000000000047ecf2 in _internal_activate_generic (self=self@entry=0xc8d150, active=active@entry=0xcc33b0, error=error@entry=0x7fffa5cc4958) at nm-manager.c:2712
#6 0x000000000047ef2b in _internal_activation_auth_done (active=0xcc33b0, success=<optimized out>, error_desc=0x0, user_data1=0xc8d150, user_data2=<optimized out>) at nm-manager.c:2848
#7 0x0000000000466fa1 in auth_done (chain=0xcef020, error=0x0, unused=<optimized out>, user_data=<optimized out>) at nm-active-connection.c:603
#8 0x00000000004753da in auth_chain_finish (user_data=0xcef020) at nm-manager-auth.c:88
#9 0x0000003370c492a6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#10 0x0000003370c49628 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#11 0x0000003370c49a3a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#12 0x0000000000429e65 in main (argc=1, argv=0x7fffa5cc4e48) at main.c:678
Signed-off-by: Thomas Haller <thaller@redhat.com>
Something changed at some point so that NMManager was now recomputing
its state after a connection was activated, but before NMPolicy had
decided whether to give that connection the default route, meaning
NMManager would set the state to CONNECTED_LOCAL rather than
CONNECTED_GLOBAL.
Fix this by watching the active connection :default and :default6
properties too, so we do the right thing regardless of what order the
AC properties change in.
The NMDevice dispose() function contained some badly-duplicated logic
about when to deactivate a device on its last ref. This logic should
only run when the device is removed by the manager, since the manager
controls the device's life-cycle, and the manager knows best when to
clean up the device. But since it was tied to the device's refcount,
it could have run later than the manager wanted, or not at all.
It gets better. Dispose duplicated logic that was already done in
nm_device_cleanup(), and then *called* nm_device_cleanup() if the
device was still activated and managed. But the manager already
unmanages the device when removing it, which triggers a call to
nm_device_cleanup(), takes the device down, and resets the IPv6
sysctl properties, which dispose() duplicated too. So by the time
dispose() runs, the device should already be unmanaged if the
manager wants to deconfigure it, and most of the dispose() code
should be a no-op.
Clean all that up and remove duplicated functions. Now, the flow
should be like this:
1) manager decides to remove the device and calls remove_device()
2) if the device should be deconfigured, the manager unmanages
the device
3) the NMDevice state change handler tears down the active connection
via nm_device_cleanup() and resets IPv6 sysctl properties
4) when the device's last reference is finally released, only internal
data members are freed in dispose() because the device should
already have been cleaned up by the manager and be unmanaged
5) if the device should be left running because it has an assumable
connection, then the device is not unmanaged, and no cleanup
happens in the state change handler or in dispose()
The following procedure leaves an NMActiveConnection around for a deactivated
device, which causes errors in libnm-glib clients when they cannot create the
GObject for the non-existent device of the AC.
1) allow a device which can assume connections to be activated
2) stop NM, which should leave the device's IP configuration up
3) start NM and allow it to assume the device's existing connection
4) remove the device, either by unplugging it or 'rmmod'
The device is removed by nm-manager.c::remove_device(), but the device object
is not moved to UNMANAGED state, leaving the NMActiveConnection completely
unaware the device has gone away.
The nm-manager.c::remove_device() code did not correctly handle moving a
forcibly removed (eg, by unplugging or 'ip link del' or 'rmmod') device to
the UNMANAGED state when the device was active with an assumed connection.
To fix this, make the conditions when the device should be deactivated
on removal much more explicit.
A device should be deactivated on removal if:
1) it is forcibly removed, eg by the kernel network interface being
removed due to 'ip link del' or hotplugging, or internally by NM due
to a parent WWAN interface taking priority over a WWAN ethernet interface
2) if the device cannot assume connections, in which case NetworkManager
must have activated the device and since we cannot assume the connection
on restart, we should deactivate it
3) if the device is not activated, to ensure that its IPv6 parameters
and other things get reset to the pre-NetworkManager values
https://bugzilla.gnome.org/show_bug.cgi?id=729833
CC nm-manager.lo
nm-manager.c: In function 'assume_connection':
nm-manager.c:1605:345: error: 'return' with no value, in function returning non-void [-Werror=return-type]
g_return_if_fail (nm_device_get_state (device) >= NM_DEVICE_STATE_DISCONNECTED);
Minor error, introduced by commit f229f4e201.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
Instead of having a GObject property and a factory function to get
the plugin's device type, just use the factory function, since it
always has to be around.
Make Wi-Fi support a plugin using the new device factory interface.
Provides a 7% size reduction in the core NM binary.
Before After
NM: 1154104 1071992 (-7%)
Wi-Fi: 0 110464
(all results from stripped files)
Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained
kernel rfkill subsystem integration with 2.6.33. Before then their
custom rfkill functionality had to be polled via sysfs. Since we now
require at least a 3.x kernel, remove this old code.
It's only used to keep the DHCPManager up-to-date with hostname changes,
and that can be accomplished in much less code by just having NMManager
set a hostname on the DHCPManager itself.
rfkill handling should only pay attention to actual rfkill, since
rfkill is global but the modem management service state is per-device.
Thus calculating a global state from multiple devices is very
likely to get things wrong.
Remove all of the code that used to handle that sort of thing,
which means removing the 'enable-changed' signal from the Modem
device, since now nothing external to the modem device should
need to care whether it's enabled internally or not.
Poke the kernel's WWAN rfkill state when the user changes our
WWANEnabled property, the same as we do for WiFi. Also restore
saved WWAN state on startup, as we do for WiFi. No good reason
why WWAN should be different here.
Before platform raised 3 signals for each object type. Combine
them into one and add a new parameter @change_type to distinguish
between the change type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When assuming the connections on restart we want to prefer more-recently-used
connections. That's why we have to sort connections according to timestamps in
descending order. That means connections used more recently (higher timestamp)
go before connections with lower timestamp.
https://bugzilla.redhat.com/show_bug.cgi?id=1067712
Instead of waiting until the device is disposed and dbus-glib does
it for us, remove them when the Manager is done with them. If
something (like pending D-Bus calls) holds a reference to the device
when the Manager removes it, the device would previously still
service method calls until all references are released. When
the device is removed, it's dead, and it shouldn't be exported
anymore.
We'll want to track internal management separately in the future, so split out
user management (eg, whether the device has been explicitly marked unmanaged
by the user).
Instead of tracking unmanaged-ness in a couple variables (and because
I'd like to add one for user-unmanaged later) let's do it in a single
flags variable, and consolidate setting of the unmanaged states in one
place.
