Allows better encapsulation of the functionality of the NMSettings
object that we want to expose to the device class. They don't need
the whole object so to keep things simple and contained we'll just
give them a smaller interface to use.
This is similar to clicking a Wi-Fi network's SSID in a GUI applet.
The command does this:
- creates new connection (fills the user data specified via options, the
connection is then completed with default parameters by NM)
- and then activates the connection on a Wi-Fi device.
WPA-Enterprise is not supported as it requires a plethora of parameters and
they can't be obtained automatically.
Also, the created connection uses 'auto' IP method, which means that if the
Wi-Fi network doesn't support DHCP, the connection will albeit be created,
however the activation will fail (IP configuration won't be available).
Now that we've encountered this twice with distros disabling WEXT
but apparently not realizing it kills staging and out-of-kernel
drivers like wl.o, make it a log message so we don't have to go
hunting for build-time logfiles.
When copying device names into ioctl structs, we know that the device
names are of valid length, so we were using strcpy(). But you can't
prove that they're short enough just looking at the local code, so
some code analysis tools warn about a potential buffer overflow.. So
use g_strlcpy() instead.
A vlan DEVICE name must be either $(OTHERDEVICE).$(VLAN_ID) or
vlan$(VLAN_ID). Enforce that. In particular, don't:
(a) crash if the name has no "." and doesn't start with "vlan",
(b) loop forever if the $(VLAN_ID) part is non-numeric, or
(c) silently ignore non-numberic characters after the $(VLAN_ID).
The signal is private for libnm-glib and should not be used externally.
It is emitted when there's an error while creating an object.
In addition, this commit makes use of the signal in NMClient to ensure
that the callbacks are always called for nm_client_activate_connection()
and nm_client_add_and_activate_connection().
Otherwise if a client holds references to the objects (or in the
JavaScript case, uses deferred garbage collection) they'll still
be in the cache when NM restarts, and the old object may have the
same path as some new object, which isn't good.
When NMClient changes state to "not running", don't just unref all the
devices and connections: emit notify::active-connections and
device-removed signals too, so the app will drop its copies of them.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
In some situations, objects might get used after being disposed, so
clear out their various priv fields so we don't try to access unreffed
objects, freed strings, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
No idea *why* they're NULL, unless perhaps that dbus-glib can't demarshal
the variants for some reason, but until we know why at least log the
problem so we know what properties the issue might affect.
If a client keeps the connection around after NMRemoteSettings is done
with it (and has emitted 'removed' for that connection) then the
RemoteSettings object was still registered to receive signals for
that connection. To prevent clients from being able to screw up
the RemoteSettings, disconnect any signals it may be listening for
when the connection is removed. (it should be doing that anyway)
The kernel wants there to be a default route over every RA-ed IPv6
interface, and it gets confused and annoyed if we remove that default
route and replace it with our own (causing it to effectively drop all
further RAs on the floor, which is particularly bad if some of the
information in the earlier RA had an expiration time).
So, rather than replacing the kernel's default route(s), just add an
additional one of our own, with a lower (ie, higher priority) metric.
https://bugzilla.redhat.com/show_bug.cgi?id=785772
This reverts commit dd0460697c.
The commit dd0460697c make nm_remote_settings_new()
create the NMRemoteSettings object synchronously. It fixed getting properties,
but undid the previous ability to initialize the object asynchronously.
It can be reverted now, because a4f450aa0b commit
ensure initialization in get_property() calls.
We need to do _nm_object_ensure_inited() /
_nm_remote_settings_ensure_inited() from the get_property()
implementations; in most cases, get_property() just calls another
accessor method (which will call _nm_object_ensure_inited()), but in a
few places, it reads priv->whatever directly, so we need to make sure
that it's valid.
Most of the stuff was done by 762df85234.
But to allow this piece of code:
from gi.repository import NMClient
nmclient = NMClient.Client()
print nmclient.get_active_connections()
we also need to set "dbus-path" property in NMClient constuctor(),
else parent NMObject is not properly constructed.
