result_cb invokes a function pointer provided by the user. Nothing prevents
the user from destroying the NMRemoteConnection in the callback, which leads
to a crash. Take an additional ref of NMRemoteConnection to keep it
alive.
This probably caused a crash for nm-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=1030403
Signed-off-by: Thomas Haller <thaller@redhat.com>
deferred_notify_cb() needs to take a ref on the object around emitting
its deferred signals, since otherwise if a notify:: handler drops the
last reference on an object, a following g_object_notify() call would
crash.
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
When connecting to a hidden SSID, the Access Point object that NetworkManager
creates will have no frequency, because the frequency is unknown until the
connection succeeds. The warning has no use; if the AP doesn't have a
frequency then it even match a connection with a specified frequency.
We have to check if 'client' is valid when calling _nm_object_ensure_inited().
Creation of NMClient object can fail, because its parent NMObject's
constructor() returns NULL for D-Bus errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1010288
gtk-doc recognizes that #NMFoos is the plural of #NMFoo now, so you
don't need to put an empty comment between the type name and the "s"
to make it work. (Unfortunately, it's not smart enough to realize that
"NMIP4Addresses" is the plural of "NMIP4Address".)
Also, add some missing "#"s noticed along the way.
Running `make check` on systems without running dbus failed
in test-remote-settings-client.c:383
make[4]: Entering directory `/tmp/NetworkManager/libnm-glib/tests'
/tmp/NetworkManager/libnm-glib/tests/test-remote-settings-client /tmp/NetworkManager/libnm-glib/tests test-remote-settings-service.py
** (/tmp/NetworkManager/libnm-glib/tests/.libs/lt-test-remote-settings-client:26983): WARNING **: Error connecting to D-Bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
make[4]: *** [check-local] Trace/breakpoint trap (core dumped)
Modify the Makefile to start the dbus-daemon, if it is not yet
running.
Signed-off-by: Thomas Haller <thaller@redhat.com>
All NMObjects created in response to property changes were getting
leaked, which in particular included all NMAccessPoint objects, which
meant that after disconnecting and reconnecting a wifi interface some
number of times (depending on how many access points were in the
area), gnome-shell would be watching so many D-Bus AccessPoint objects
(most of which didn't exist any more) that it would hit dbus-daemon's
limit on the number of match rules you can register, which meant that
NMActiveConnections created after that point wouldn't be able to
register for PropertiesChanged notifications, which meant that the
network status icon would get out of sync.
Use an environment variable LIBNM_GLIB_DEBUG=properties-changed to
indicate that properties-changed debugging messages should be printed.
Also cleans up the debug output formatting.
The errors were documented as org.freedesktop.NetworkManager.VPN.Error.*,
but the actual values were org.freedesktop.NetworkManager.VPN.Plugin.*
Also update the errors documentation.
The ConnectInteractive() -> Connect() fallback code doesn't work, because
_connect_internal() changes the state to NM_VPN_SERVICE_STATE_STARTING before
checking if it can implement ConnectInteractive(), and then when the Connect()
call comes in, the VPN is not in STOPPED or INIT, so it returns an error.
The commit moves setting state to STARTING after the ConnectInteractive() check
availability, in the plugin. We introduce new plugin error and set it when the
the plugin does not implement ConnectInteractive(). NetworkManager uses this
error for ConnectInteractive() -> Connect() fallback.
https://bugzilla.gnome.org/show_bug.cgi?id=708255
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
IPoIB "hardware addresses" are only partly based on the hardware, and
partly based on the InfiniBand configuration. So when checking if a
configuration matches a device, we should only match the fixed part.
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
If you called nm_remote_connection_delete() on a connection whose only
ref was held by the NMRemoteSettings, then the callback would never
get called, because NMRemoteSettings would drop its ref before then
(when the connection emitted the 'removed' signal), so the callback
would get cancelled.
Fix this by taking an extra ref on the connection around the D-Bus
call in this case.
https://bugzilla.redhat.com/show_bug.cgi?id=997568https://bugzilla.gnome.org/show_bug.cgi?id=706141
A common case where this warning was triggered, was the removal of
IP6Config objects. As this can happen as a regular event, do not warn in
this case.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
There are three additions to the D-Bus interface for VPN plugins as
part of this patch:
1) ConnectInteractive(): called by NM instead of Connect() to let
the plugin know that it can request additional secrets during the
connection process using SecretsRequired
2) SecretsRequired: a new signal emitted by the plugin to indicate
to NetworkManager that additional secrets are required to connect;
can only be called if NetworkManager initiated the connection by
calling the ConnectInteractive() method
3) NewSecrets(): a new method of the plugin that NetworkManager calls
when new secrets requested by the SecretsRequired signal have been
retrieved from secret agents
We need new methods because agents need to be aware of the hints that
the VPN plugins may send with the SecretsRequired signal (detailing
the specific secrets that are required) and at this time, not all
agents support passing those hints to the VPN plugin authentication
dialogs.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
Add a new libnm-glib method to get the type description for a device,
and use it in nmcli. For most types, the type description is based on
the class name, but for NMDeviceGeneric, it comes from the
:type-description property.
