Deleting an IPv4 address using libnl requires the proper peer address.
Pass the address of the peer on to nm_platform_ip4_address_delete().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Seems like 128k is not enough for systems with many interfaces. This adds 4k
per device, while keeping the 128k minimum. Therefore this change only
affects systems with more than 32 interfaces.
https://bugzilla.redhat.com/show_bug.cgi?id=1141256
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
In preparation for porting to GDBus, make nm_connection_to_dbus(),
etc, represent connections as GVariants of type 'a{sa{sv}}' rather
than as GHashTables-of-GHashTables-of-GValues.
This means we're constantly converting back and forth internally, but
this is just a stepping stone on the way to the full GDBus port, and
all of that code will go away again later.
libnm-util's connection deserializing/copying/replacing functions have
odd semantics where sometimes they both modify a connection AND return
an error. libnm-core tried to improve things by guaranteeing that the
connection would not be modified if the new settings were invalid, but
this ended up breaking a bunch of places that needed to be able to
work with invalid connections. So re-fix the functions by reverting
back to the old semantics, but having return values that clearly
distinguish whether the connection was modified or not.
For comparison:
- nm_connection_new_from_hash() / nm_simple_connection_new_from_dbus():
- libnm-util: returns a valid connection or NULL.
- OLD libnm-core: returned a valid connection or NULL.
- NEW libnm-core: returns a valid connection or NULL.
- nm_connection_duplicate() / nm_simple_connection_new_clone():
- libnm-util: always succeeds, whether or not the connection is
valid.
- OLD libnm-core: returned a valid connection or NULL
- NEW libnm-core: always succeeds, whether or not the connection
is valid.
- nm_connection_replace_settings_from_connection():
- libnm-util: always replaces the settings, but returns FALSE if
the connection is now invalid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: always replaces the settings, and has no
return value. (The modified connection is valid if and only if
the replaced-from connection was valid; just like with the
libnm-util version.)
- nm_connection_replace_settings():
- libnm-util: returns TRUE if the new settings are valid, or
FALSE if either (a) the new settings could not be deserialized
and the connection is unchanged, or (b) the new settings were
deserialized, and the connection was updated, but is now not
valid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: returns TRUE if the connection was updated
(whether or not it is valid), or FALSE if the new settings
could not be deserialized and the connection is unchanged.
UINT is just 32bit, truncating the GType on 64-bit platforms. We do already use
cast to SIZE, which is as wide as a pointer, when we need a GType in another
place (nmtui); let's do it here as well.
Broken by [0bc1b5138] core: add support for internal device factories
https://bugzilla.gnome.org/show_bug.cgi?id=736780
DHCP client may be killed by SIGPIPE when attempting to write to a broken pipe.
This can be observed, for example, when journald is restarted.
Fix that by redirecting both stdout and stderr to /dev/null. The client logs
into syslog anyway. When NetworkManager is run with '--debug' we duplicate
syslog to stderr, so the messages goes to terminal as well.
Testcase:
- start a NetworkManager service by systemd
- activate an DHCP ethernet connection
- sudo systemctl restart systemd-journald.service
- reactive the ethernet connection (nmcli con up <my-eth>)
- DHCP client is killed by SIGPIPE right after its startup:
<info> (enp0s25): DHCPv4 client pid 13959 exited with status -1
<warn> DHCP client died abnormally
Another possible fix would be ignoring SIGPIPE in the DHCP client as it is not
useful in most cases. E.g. systemd ignores SIGPIPE for its services, by
default:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1bhttps://bugzilla.gnome.org/show_bug.cgi?id=735962
gcc's linker does not add constructors from object files to the main
executable if they are built into a convenience library and then the
library is linked to the executable, unless something outside of the
object file with the constructor references a symbol from the object
file.
http://osdir.com/ml/libtool-gnu/2011-06/msg00003.html
"Yes, when convenience libraries are used to create a shared library, all the
objects are included in the output, when the output is an application they are
used like a normal archive library.
Either use them to create a shared library or, if creating an application,
don't use them, use the objects instead."
Further patches will remove all references to the NMDevice subclasses
from nm-manager.c, and have each NMDevice subclass register itself
with a factory through a constructor. But due to the above issue,
we need to somehow ensure the constructor in each nm-device-*.c file
gets added to the executable. This is accomplished by explicitly
linking each NMDevice subclass' object file into the main executable.
(Note that we cannot use -Wl,-whole-archive here because libtool only
supports this option for linking a convenience library to a shared
library, but not to an executable, and will actively prevent using
-whole-archive in LDFLAGS)
In preparation for internal device types exposing factories too, it's
easier to have the device type that the factory creates be returned
by the factory object instead of the plugin, because internal device
types don't have plugins.
This requires that we create the factory objects earlier, which
further requires that any operations that trigger signals must be
moved out of each factory's construction path to a separate start()
function.
Instead of creating it in NMSettings, where we must use
NM_IS_DEVICE_ETHERNET() (not NM_DEVICE_TYPE_ETHERNET because various generic
devices masquerade as NM_DEVICE_TYPE_ETHERNET too), push knowledge
of which device types create default wired connections into the device
types themselves. This solves a problem with testcases where
libNetworkManager.a (which testcases link to) requires the symbol
nm_type_device_ethernet().
Instead of having basically the same code in a bunch of different
place to find helper programs, just have one place do it. Yes, this
does mean that the same sequence of paths is searched for all helpers
(so for example, dnsmasq will no longer be found first in /usr/local)
but I think consistency is the better option here.
https://bugzilla.gnome.org/show_bug.cgi?id=734131
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.
