vxlan_info_data_parser() must take care of missing netlink attributes.
Otherwise, older kernels will crash NM.
Also, workaround compilation against old kernel headers which are
missing 'struct ifla_vxlan_port_range'. We do this by defining our
own 'struct nm_ifla_vxlan_port_range' version.
Reported-by: Javier Jardón <jjardon@gnome.org>
Signed-off-by: Thomas Haller <thaller@redhat.com>
For PAN devices we create an unsaved connection if no matching
connection exists. After the device gets removed, we want to clean
up that connection, unless it was modified/saved in the meantime.
Before this was accomplished by creating a clone of the original
connection. When deciding whether the temporary connection was
modified, we would compare the current state with the original.
This can now be simplified, because we have the nm-generated flag
that gets cleared whenever the user modifies or saves the connection.
This code is also more robust, because the previous implementation
was a hack, but could not reliably detect whether the connection
was modified by the user.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At a few places, we checked for nm_device_uses_generated_connection()
whether to touch the device or not. nm_device_uses_generated_connection() used
to look at the "nm-generated" property of the NMSettingsConnection.
We are about to change the meaning of "nm-generated", which will mean
"any connection generated by NM, for whatever reason".
Instead now use the new "nm-generated-assumed" connection flag that has
the meaning "nm-generated" used to have.
So rename nm_device_uses_generated_connection() to nm_device_uses_generated_assumed_connection()
which looks at the "nm-generated-assumed" flag instead.
Also, be more strict in nm_device_uses_generated_assumed_connection() to require
both an "nm-generated-assumed" connection *and* an active connection that is
nm_active_connection_get_assumed().
Signed-off-by: Thomas Haller <thaller@redhat.com>
NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED_ASSUMED is a special kind of
NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED, that was generated for
connection assumption.
At the moment, the flag is used identical to NM_GENERATED. Later,
NM_GENERATED will get a slightly different meaning.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, NMSettingsConnection had two internal properties 'unsaved' and
'nm-generated'. Now, implement these properties as #NMSettingsConnectionFlags.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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
