This fixes the /libnm/client-nm-running test failure when a race condition is hit:
test-nm-client:10350): libnm-WARNING **: updated_properties:
error reading NMRemoteSettings properties:
GDBus.Error:org.freedesktop.DBus.Error.NoReply:
Message did not receive a reply (timeout by message bus)
What actually happens is that nm_running_changed_cb() calls GetAll() for a
NMRemoteSettings object when NM appears on the bus. If it disappears shortly
afterwards, another nm_running_changed_cb() is called which suppresses further
object updates, but the original GetAll() might not have finished yet and DBus
will generate a NoReply() response for it. We ought to ignore it.
They require a tty or X11 displays, thus are not suitable for headless runs
(such as in mock). Furthermore, they die with the tty or X11 session, which
is somehow late -- a lot of them may accumulate. Let's kill them right away.
The revision number of the RPM (as build by contrib/rpm) should
be increasing so that newer packages can be installed using
`yum install` and older packages can be downgraded using
`yum downgrade`.
By counting only --first-parent, the following example turns
out wrong. Note the duplicate revision numbers.
-- A(100)----------------------------F(101)----G(102)
\ /
B(101)----C(102)----D(103)----E(104)
Just count *all* parent commits
* two users are logged in: user_a and user_b
* user_b creates a connection visible only to him 'user_b_private'
(permissions: user:user_b)
* user_b activates the connection user_b_private
* user_a does not see the connection profile, but he does see the active
connection
* user_a calls
nmcli con
nmcli con show user_b_private
Test NMClient's handling of active connections, and in particular test
that we can correctly resolve the circular reference between an
NMDevice and an NMActiveConnection, both synchronously and
asynchronously.
NMActiveConnections start out in state "unknown", but then quickly
switch to "activating". Unfortunately, it's sometimes possible for
this to be externally visible. Fix this by lying and saying that state
is "activating" during the initial "unknown" stage (though not if the
state changes to "unknown" later on).
(Actually changing the initial state to "activating" breaks things
because some code depends on there being a transition into the
"activating" state.)
In some cases, the nm_client_activate_connection() callback could be
invoked when either the NMActiveConnection or the NMDevice had not
been initialized yet. Fix it to wait for both of them to be fully
initialized before invoking the callback.
3e5b3833 changed various libnm methods to return 0-length arrays
rather than NULL, and changed various other places to assume this
behavior. The guarantee that they didn't return NULL relied on the
assumption that all D-Bus properties would get initialized by NMObject
code before anyone could call their get methods.
However, this assumption was violated in the case where two objects
circularly referenced each other (eg, NMDevice and
NMActiveConnection). f9f9d297 attempted to fix this by slightly
changing the ordering of NMObjectCache operations, but it actually
ended up breaking things and causing infinite loops of object creation
in some cases.
There's no way to guarantee we never return partially-initialized
objects without heavily rewriting the object-creation code, so this
reverts most of f9f9d297 (leaving only the new comment in
_nm_object_create()). The crashes introduced by 3e5b3833 will no
longer happen because we've now fixed the classes to have initialized
their object arrays to non-NULL values even before they get the real
values.
In some cases, code may look at the value of an array-valued property
during object initialization, before NMObject has set it to its actual
initial value. So ensure that we initialize all such properties to an
empty array, rather than leaving them NULL.
Also fix another bug in NMClient that could result in
priv->active_connections being NULL during certain signal emissions,
and fix nm_client_get_active_connections() to not return NULL when NM
was not running.
PPPoE connections involve two different network connections, making it
ambiguous what the "Device" field refers to. Clarify that it refers to
the Ethernet device, not the PPP device.
Routing configuration fails to apply if the device is not IFF_UP, so if
we're going to apply IP configuration to the device, make sure it's IFF_UP
first.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
When a child device is found and an IP configuration already exists
for it even though it is under NM control (like when pppd applies
IP config to a WWAN device before NM gets the IP details from the pppd
plugin), don't deconfigure the child device when removing it from the
device list, because this breaks the device's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=738479
A generated connection contains a copy of the device's existing
configuration, so it's entirely redundant to merge the connection
back into the device's IP config. But even though that should
result in no changes to the IP config, NMSettingIPxConfig treats a
route metric of '0' as the device priority, while NMIPxConfig
allows 0 as a valid route metric. Since the setting values
are preferred (they are supposed to be user-supplied and thus
override anythign else, but in this case they are generated and
thus not user-supplied) external routes with a metric of 0 are
overwritten with the device priority metric.
https://bugzilla.gnome.org/show_bug.cgi?id=738268
When using a private bus connection, the service is never marked
as running when settings are initialized asynchronously. Successfully
opening a socket in NM's runtime directory should already imply
a running service, so just mark it as such (as we already do in
the synchronous path).
This adds service discovery via SDP and RFCOMM tty management to
NetworkManager, as it was dropped from Bluez.
Based on work by Dan Williams <dcbw@redhat.com>.
The SDP discovery is based on code from Bluez project.
We'll need it for bluez5 DUN support.
[lkundrak@v3.sk: Turn the addresses to strings from guint8[ETH_ALEN], as that
is what rest of NetworkManager uses for MAC addresses and what Bluez utility
functions expect as well.]
