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.
Bonding and InfiniBand are done. Bridging isn't, but after removing
the bonding and generic infrstructure parts of that section, there
wasn't really enough left to be worth keeping.
Reset all known bond options to their default values, not just the
ones that NMSettingBond allows overriding. Also, remove any bond
slaves that were already attached to the bond before we managed it.
Only update bond parameters that need to be updated. In particular,
setting either arp_interval or miimon to 0 has the side effect of also
setting the other one to 0, so don't do that if it's already 0.
Fix the handling of arp_ip_target; the sysfs arp_ip_target node does
not work the same way as the ifcfg BONDING_OPTS line (which is what
the code was assuming before).
Add NM_SETTING_BOND_ERROR_INVALID_OPTION and
NM_SETTING_BOND_ERROR_MISSING_OPTION error codes so we can better
distinguish errors in different options, and add checks for various
incompatible sets of options.
NMSettingBond sets the "miimon" option to "100" by default, but this
means that when reading in a saved configuration with "arp_interval"
set, it would end up with both "miimon" and "arp_interval" set, which
is invalid. Fix this by clearing "miimon" if "arp_interval" is set,
and vice versa.
