NM keeps interfaces IFF_UP when possible to receive link layer
events like carrier changes. Unfortunately, the kernel also
uses IFF_UP as a flag to assign an IPv6LL address to the interface,
which results in IPv6 connectivity on the link even if the interface
is not supposed to be activated/connected.
NM sets disable_ipv6=1 to ensure that the kernel does not set up
IPv6LL connectivity on interfaces when they are not supposed to
be active and connected. Unfortunately, that prevents users from
manually adding IPv6 addresses to the interface, since they expect
previous kernel behavior where IPv6 is enabled whenever the
interface is IFF_UP.
Furthermore, interfaces like PPP and some WWAN devices provide
misleading information to the kernel which causes the kernel to
create the wrong IPv6LL address for the interface. The IPv6LL
address for these devices is obtained through control channels
instead (IPV6CP for PPP, proprietary protocols for WWAN devices)
and should be used instead of the kernel address. So we'd like
to suppress kernel IPv6LL address generation on these interfaces
anyway.
This patch makes use of the netlink IFLA_INET6_ADDR_GEN_MODE
attribute to take over assignment of IPv6LL addresses while
keeping the interface IFF_UP, to ensure there is only IPv6
connectivity when the user requests it.
To remain compliant with standards, if a user adds IPv6 addresses
externally, NetworkManager must also immediately add an IPv6LL
address for that interface too.
https://bugzilla.gnome.org/show_bug.cgi?id=734149
This patch requires both upstream kernel support for
IFLA_INET6_ADDR_GEN_MODE which was merged in this patch:
ipv6: addrconf: implement address generation modes
bc91b0f07ada5535427373a4e2050877bcc12218
and corresponding libnl support, merged in these patches:
veth: add kernel header linux/veth.h for VETH defines
9dc6e6da90016a33929f262bea0187396e1a061b
link: update copy of kernel header include/linux/if_link.h
b51815a9dbd8e45fd2558bbe337fb360ca2fd861
link/inet6: add link IPv6 address generation mode support
558f966782539f6d975da705fd73cea561c9dc83
Change NMSettingDCB's guint-array properties to G_TYPE_ARRAY, with
annotations indicating the element type.
Since DBUS_TYPE_G_UINT_ARRAY was already represented as a GArray, this
does not require any changes anywhere else.
Change all DBUS_TYPE_G_UCHAR_ARRAY properties to G_TYPE_BYTES, and
update corresponding APIs. Notably, this means they are now refcounted
rather than being copied.
Update the rest of NM for the changes. The daemon still converts SSIDs
to GByteArrays internally, because changing it to use GBytes has lots
of trickle-down effects. It can possibly be changed later.
APIs that take arbitrary data should take it in the form of a pointer
and length, not a GByteArray, so that you can use them regardless of
what format you have the data in (GByteArray, GBytes, plain array,
etc).
Make the :addresses and :routes properties be GPtrArrays of
NMIP4Address, etc, rather than just reflecting the D-Bus data.
Make the :dns properties be arrays of strings rather than arrays of
binary IP addresses (and update the corresponding APIs as well).
Change all DBUS_TYPE_G_MAP_OF_STRING properties to G_TYPE_HASH_TABLE,
with annotations indicating they are string->string. Not much outside
libnm-core needs to changed for this, since DBUS_TYPE_G_MAP_OF_STRING
was already represented as a hash table.
(One change needed within libnm-core is that we now need to copy the
hash tables in get_property(), or else the caller will receive a
reffed copy of the object's own hash table, which we don't want.)
Change all DBUS_TYPE_G_LIST_OF_STRING and DBUS_TYPE_G_ARRAY_OF_STRING
properties to G_TYPE_STRV, and update everything accordingly.
(This doesn't actually require using
_nm_setting_class_transform_property(); dbus-glib is happy to transform
between 'as' and G_TYPE_STRV.)
Make all mac-address properties (including NMSettingBluetooth:bdaddr,
NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be
strings, using _nm_setting_class_transform_property() to handle
translating to/from binary form when dealing with D-Bus.
Update everything accordingly for the change, and also add a test for
transformed setting properties to test-general.
NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the
same code to generate a default interface name. Move it into
nm_utils_complete_generic().
Remove the virtual :interface-name properties and their getters, and
use property overrides to do backward-compat handling when
serializing/deserializing.
Now when constructing an NMConnection from a hash, if the virtual
property is set and the NMSettingConnection property isn't, then the
override for NMSettingConnection:interface-name will set that property
to the value of the virtual interface-name. And when converting an
NMConnection to a hash, the overrides for the virtual properties will
return the value of NMSettingConnection:interface-name.
Add a method to determine if a connection applies to a virtual device.
Perhaps eventually the logic should be spread across the NMSetting
classes, but for now it's better off having it in NMConnection than
once in NMManager and once in nmcli.
The virtual :interface-name properties (eg,
NMDeviceBond:interface-name) are deprecated in favor of
NMSettingConnection:interface-name, and nm_connection_verify() ensures
that their values are kept in sync. So (a) there is no need to set
those properties when we can just set
NMSettingConnection:interface-name instead, and (b) we can replace any
calls to the setting-specific get_interface_name() methods with
nm_connection_get_interface_name() or
nm_setting_connection_get_interface_name().
Since we enforce the fact that bond, bridge, team, and vlan
interface-name properties match NMSettingConnection:interface-name,
nm_connection_get_virtual_iface_name() can be replaced with
nm_connection_get_interface_name() basically everywhere.
The one place this doesn't work is with InfiniBand partitions (where
get_virtual_iface_name() was actually computing the name), but for the
most part we only need to care about the interface names of InfiniBand
partitions in places where we also already need to do some other
InfiniBand-specific handling as well, so we can use an
InfiniBand-specific method
(nm_setting_infiniband_get_virtual_interface_name()) to get it.
(Also, while updating nm_device_get_virtual_device_description(), fix
it to handle InfiniBand partitions too.)
Drop the NMSetting properties that were marked deprecated in
libnm-util in 0.9.10, but use nm_setting_class_add_dbus_property() to
deal with them appropriately when serializing/deserializing.
Rename nm_connection_to_hash() to nm_connection_to_dbus(), and
nm_connection_new_from_hash() to nm_connection_new_from_dbus(). In
addition to clarifying that this is specifically the D-Bus
serialization format, these names will also work better in the
GDBus-based future where the serialization format is GVariant, not
GHashTable.
Also, move NMSettingHashFlags to nm-connection.h, and rename it
NMConnectionSerializationFlags.
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.
Instead of handling iBFT (iSCSI Boot Firmware Table) in the ifcfg-rh plugin,
create a new plugin for it. This allows all distributions to use iBFT
configuration, and makes both iBFT handling and ifcfg-rh less complicated.
The plugin (like the old ifcfg-rh code) creates read-only connections backed
by the data exported by iscsiadm. The plugin does not support adding new
connections or modifying existing connections (since the iBFT data is
read-only anyway). Instead, users should change their iBFT data through
the normal firmware interfaces.
Unmanaged devices can be configured through NetworkManager.conf and the
normal 'keyfile' mechanisms.
(In the future, we'll read this data directly from the kernel's
/sys/firmware/ibft/ethernetX directory instead of iscsiadm, since the
kernel has all the information we need and that's where iscsiadm gets
it from anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=734009
Even if we never receive an RA, if there are manually-specified or external
addresses, consider IPv6 to complete successfully. No reason to fail IPv6
if we have IP configuration already, but RA doesn't respond. If RA shows
up again, we're still listening for it and will apply the config at that
time.
Reporter left SLAAC enabled (because it's default and requires being
explicitly turned off) and added manual IPv6 address. They expected that
address to be assigned very soon after starting the connection, but it was
not assigned.
This happened because NM waits for RA before assigning any IPv6 configuration,
including the manually specified addresses. In the reporters case, there was
no IPv6 router on the network, so NM waited indefinitely for a router
advertisement and never applied any IPv6 configuration.
It seems reasonable to apply any IPv6 configuration we have available, when
we have it. We already apply RA configuration before starting DHCP, and
apply DHCP configuration if/when we get that.
The IPv4 pre-commit hook was called right before the config was
committed, while the IPv6 one was called before commit in only
one case (from nm_device_activate_ip6_config_commit). The IPv4
behavior is the intended behavior.
Note that this doesn't have any actual effect yet, since nothing
actually implements the IPv6 pre-commit hook
by disconnecting signal handlers in dispose().
Commit 6a19e68a moved nm_connection_clear_secrets() from plugins' finalize() to
NMSettingsConnection's dispose(). But clearing secrets emits "changed" signal
which cause changed_cb() to be called and emit_updated() scheduled. And
emit_updated() was called later after finalize() on released object.
The crash can be invoked by having two keyfile connection files with the same
uuid in them.
Backtrace:
(NetworkManager:12262): GLib-GObject-WARNING **: attempt to retrieve private data for invalid type 'NMSettingsConnection'
Program received signal SIGSEGV, Segmentation fault.
emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
401 NM_SETTINGS_CONNECTION_GET_PRIVATE (self)->updated_idle_id = 0;
(gdb) bt
#0 emit_updated (self=0xf38dd0 [NMSettingConnection]) at settings/nm-settings-connection.c:401
#1 0x0000003c49647825 in g_main_dispatch (context=0x785970) at gmain.c:2539
#2 g_main_context_dispatch (context=context@entry=0x785970) at gmain.c:3075
#3 0x0000003c49647b58 in g_main_context_iterate (context=0x785970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3146
#4 0x0000003c49647f52 in g_main_loop_run (loop=0x7857c0) at gmain.c:3340
#5 0x000000000042d4e9 in main (argc=1, argv=0x7fffffffe508) at main.c:679
This wpa_supplicant option is not named "private_key_passwd2". Looks
like this regressed in e5ed391f28.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
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>
verify() used to modify interface-name of the base settings. This is
discouraged, because verify() should not touch the connection.
For libnm-core we can change behavior and only modify the connection
in normalize().
Also, be more strict not to verify() sucessfully on invalid
interface-name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_connection_normalize() can now add the slave setting as needed. Remove
the duplicate functionality.
This undoes commit 664d64e0c0
but the same functionality is now provided via normalize().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some NMSettingConnection:slave-type types require a matching slave #NMSetting.
Add normalization of either the 'slave-type' property or the slave-setting.
Also be more strict in NMSettingConnection:verify() to enforce an
existing slave-setting depending on the slave-type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At the end of reading the connection, reader calls nm_connection_normalize()
to normalize the connection. Normalization inplicitly verifies the
connection.
Doing a verify along the way is not needed and even harmful. Soon further
checks will be added that make verify() fail, but normalize()
can fix the connection. So, while reading, we might actually have
an invalid connection, that will be normalized as last step.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The new nm_connection_normalize() function allows to fixup an incomplete connection.
The keyfile reader should call normalize on a connection, so that we can implement
common normalizations there instead of inside the settings plugin.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The recent change c88b832ce9 allows for
missing 'id' and 'uuid' entries. Further make the keyfile reader
more accepting, by creating a missing NMSettingConnection.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a header file to expose private utility functions from libnm-core
that can be used by NetworkManager (core) and libnm.so. The header
is also used to give privileged access to libnm-core. Since NM links
statically, these functions are not exported and not part of public ABI.
This also removes the NM_UTILS_PRIVATE_CALL() macro and libnm.so no
longer exports nm_utils_get_private().
Before, this functionality was partly declared in nm-utils-private.h.
This was wrong because nm-utils-private.h is for functionality
entirely private to libnm-core.
Signed-off-by: Thomas Haller <thaller@redhat.com>
