In certain situations, ethernet links first appear with a zero MAC
address and then the MAC changes some time later. Currently NM does
not deal correctly with this scenario since it initializes wrong
@initial_hwaddr and @permanent_hwaddr on the device and tries to
immediately activate it.
To fix this, initialize the device's addresses only when the MAC
becomes valid and make the device available only at that point.
Instead of using a signal for triggering the generation of a default
connection when the device becomes managed, let the manager wait for a
transition to UNAVAILABLE or DISCONNECTED states.
This partially reverts b3b0b46250 ("device: retry creation of
default connection after link is initialized").
We cannot abort the construction of a GLib object instance
like we did for NMDeviceWifi and NMDeviceOlpcMesh when
nm_platform_wifi_get_capabilities() failed.
Instead, check the capabilities first (in the factory method)
and only create the object instance when the device can be handled.
https://bugzilla.gnome.org/show_bug.cgi?id=760154
This is the same as 04c70c76bc for the
NMIP4Config and NMIP6Config structures. The new field makes debugging
of issues related to IP configuration much easier.
We inconsistently use gulong,guint,int types to store signal handler
id, but the type returned by g_signal_connect() is a gulong.
This has no practical consequences because a int/guint is enough to
store the value, however it is better to use a consistent type, also
because nm_clear_g_signal_handler() accepts a pointer to the signal id
and thus it must be always called with the same pointer type.
Previously, we directly passed the @in_ifcfg path to find_by_path().
That means, @in_ifcfg must be the path to the base "ifcfg-" file,
not an alias or route file.
Add an additional pre-check, that the provided file name is really a
ifcfg base file.
This results in a more detailed error message when calling
GetIfcfgDetails not on the ifcfg base file. It's not that previously
the lookup would have succeeded.
If @ip_ifindex is zero, the IP interface has disappeared and
there's no point in updating @ip_iface.
Actually, unconditionally updating @ip_iface is dangerous because it
breaks the assumption used by other functions (as
nm_device_get_ip_ifindex()) that a non-NULL @ip_iface implies a valid
@ip_ifindex. This was causing the scary failure:
devices/nm-device.c:666:get_ip_iface_identifier: assertion failed: (ifindex)
https://bugzilla.redhat.com/show_bug.cgi?id=1268617
Set @ppp_watch_id to zero upon pppd termination, otherwise the call to
g_source_remove(priv->ppp_watch_id) in dispose() could trigger a failed
assertion.
Otherwise the lacking IS_SOFTWARE capability may cuase the connections not to
be available on software devices and the devices would get garbage-collected at
the end of unrealize().
Add test showing how libnm/libnm-glib handles invalid connections,
i.e. connections that fail nm_connection_verify(). libnm implements
settings a static types (via different NMSetting types). This makes
it unavoidable that eventually a newer server version will
expose connections that fail verification in the client.
For example, master added a new base type NMSettingTun. This setting type
was not backported to legacy libnm-glib, thus such connection will not verify.
Also, we want that newer server versions are backward compatible with older
library versions. Thus also a pre-NMSettingTun libnm version has the same
problem.
The test shows that libnm is agnostic to whether the connection verifies.
That is consistent behavior, but possibly problematic because most
accessors to connections assert against a valid connection. Thus using
the common nm_connection*() functions on an invalid connection can lead
to problems.
Also, due to the static nature of our NMSetting types, some properties
can be silently dropped and thus mangling the connection without the
library user noticing.
libnm-glib prints a g_warning() whenever parsing an invalid connection.
When an invalid connection is added initially, it is exposed to the library
user. When a connection gets later invalidated due to an update, the
connection disappears and it stays missing even if a subsequent update
makes the connection valid again.
libnm-glib's behavior indicates that we might wanted to hide invalid
connections from the user. But it's very broken there.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
The unit tests for libnm and libnm-glib use a NetworkManager stub
service written in Python (test-networkmanager-service.py). As they
share the same server, it makes sense to also share the same utility
code to drive the stub.
Move the common code to include/.
Note that contrary to "nm-test-utils.h", "nm-test-libnm-utils.h" is not
a header-only file. Instead its implementation is in "nm-test-utils-impl.c".
The reason for that this split is, if we later have yet another non-header-only
test-utility, then all the implementations are in "nm-test-utils-impl.c", requiring
the tests to link only one object file.
