Note that this will cause the nm_device_wifi_get_access_points() to
return hidden-SSID access point objects immediately, which it
previously did not do until added/removed signals were sent by
NetworkManager for a hidden SSID AP. Some clients may not handle
this correctly, but given that they would have crashed when the
first hidden SSID AP was found anyway, they should just be fixed.
With the addition of D-Bus properties for object-array properties in
NetworkManager core, libnm-glib can use these properties instead of
the pseudo-property stuff. However, we need to maintain API and
provide individual added/removed signals for these properties, and
that requires diff-ing the new and old object arrays. Add the
infrastructure for doing that.
The original GetAccessPoints() method call never returned hidden SSID
access points. That's useful though, and the new AccessPoints
property returns all of them too, so add this new method to return
all access points, including hidden SSID ones.
Fix a crash caused by "merge: remove at_console..." when a scan request
comes in via the D-Bus interface. This usage of the device "auth-request"
signal was missed the first time around.
Remove at_console, ensuring that all necessary calls are protected by
PolicyKit authorization (which at_console is redundant with). Allows
sessions that are not necessarily local (like SSH or remote desktop)
to talk to NetworkManager, subject to administrator PolicyKit rules.
at_console permissions as implemented by D-Bus have some problems:
1) it is now fully redundant with PolicyKit and session tracking via
systemd/ConsoleKit
2) it uses a different mechanism than PolicyKit or systemd to determine
sessions and whether the user is on local or not (pam_console)
3) it was never widely implemented across so removing it
harmonizes D-Bus permissions on all supported distros
To that end, remove the at_console section of the D-Bus permissions,
and rely on session-tracking and PolicyKit to ensure operations are
locked down.
No changes are being made to PolicyKit or session-tracking, so any
operations denied by those mechanisms are still denied, and no
permissions are being relaxed. Instead, this should allow remote
users who log in via remote desktop or SSH to inspect network state,
change connection parameters, and start/stop interfaces. Obviously
if you are remote, you should not touch the interface which your
connection is using, but that concern shouldn't prevent all the other
nice stuff that you can do with NM.
https://bugzilla.gnome.org/show_bug.cgi?id=707983https://bugzilla.redhat.com/show_bug.cgi?id=979416
This function returns the number of sessions found, but the return
value wasn't being correctly handled for errors. Also fix the
require_active parameter value to be 100% clear about what NM wants.
While this function only returns the path of the requested connection
(the actual settings are always protected), callers that aren't in
the connection's ACL still probably shouldn't get that, if only to
be pedantic.
Now that the objects get replaced when IP configuration changes
instead of being destroyed and a new one created, they need
PropertiesChanged signals.
(noticed as a result of auditing all exported D-Bus objects)
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
Since IPv6 configuration gets updated every time a router advertisement
comes in, it can lead NM to continuously logging:
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
that's annoying. So after the initial configuration is done, make
subsequent IPv6 Commit log messages debug instead of info.
Don't disable IPv6 when we're about to assume a connection that may well
have IPv6 already configured on the interface, which removes all addresses
and routes from the interface and generally Breaks Stuff.
When disconnecting a master device, propagate its NMDeviceStateReason
to the slaves. That way, if the reason is USER_REQUESTED, then the
slaves will be blocked from re-autoconnecting as well.
NMActiveConnection was categorizing all deactivation of master
connections as "failure", and NMActRequest was deactivating all of the
master's slaves with REASON_DEPENDENCY_FAILED no matter what the real
reason was.
In fact, NMActiveConnection only needs to handle the cases where the
master fails before enslaving the device; any failure after that point
will be caught by existing master/slave checks in NMDevice. So update
the code accordingly (and remove the master_failed code from
NMVpnConnection entirely, since no master supports having VPN slaves).
If a master activation failed early (eg, because the virtual device
could not be created), then the slaves were not being notified of the
failure. Fix that.
Add a property to NMDevice that can be used to tell whether the device
is enslaved, and if so what its master is.
This is currently internal-only, but it could be exported later
perhaps.
Virtual devices may be created and destroyed, but we need to keep
their autoconnect state across that. Previously this was handled by
NMManager, but it really belongs with the other autoconnect tracking
in NMPolicy and NMSettingsConnection.
This also fixes a bug where NMPolicy would sometimes decide to
autoactivate a virtual device connection which NMManager would then
have to cancel.
When a device is disconnected by the user (as opposed to due to
network or hardware error, etc), set it first to DEACTIVATING, which
does nothing but queue a transition to disconnected. This lets other
parts of NM observe the device when it is about-to-disconnect, but
still has an associated connection.
NMPolicy was resetting the "don't autoconnect because we don't have
secrets" state on a connection when the autoconnect-retries timer
timed out, but this doesn't make sense, since the timeout doesn't
change the fact that there are no secrets.
https://bugzilla.gnome.org/show_bug.cgi?id=670631
NMPolicy was clearing the autoconnect-blocked state on a connection
any time a device with that connection changed state. This happened to
basically do the right thing, but it would be clearer if we only reset
the state after successfully getting past the NEED_AUTH stage.
NMSettings (and NMConnectionProvider) had a signal to indicate when it
had loaded the connections, but in reality this always happened before
nm_settings_new() returned (as a side effect of calling
unmanaged_specs_changed()) and so no one else would ever actually see
the signal. So just kill it.
In information-only mode (where RA is providing addresses), DHCPv6
may not give an address. NetworkManager was adding a blank one
anyway, which is invalid. Don't do that.
As nmcli changes the syntax for the 'connection show' command,
this patch for bash completion also breaks several cases when
completing for an old nmcli command.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When there are multiple connection profiles of the same name, we used to take
and process only the first one.
We change the behaviour to process all the connections now in these commands:
nmcli connection show <duplicated name>
nmcli connection down <duplicated name>
nmcli connection delete <duplicated name>
Handle connection profiles in a single 'show' command instead of 'show active'
and 'show configured'.
nmcli con show [--active] [[id|uuid|path|apath] <bla>]
nmcli con show : display all connection profiles
nmcli con show --active : only display active connection profiles
(filters out inactive profiles)
nmcli con show myeth : display details of "myeth" profile, and also active
connection info (if the profile is active)
nmcli -f profile con show myeth : only display "myeth"'s static configuration
nmcli -f active con show myeth : only display active details of "myeth"
nmcli -f connection.id,ipv4,general con show myeth
: display "connection.id"a property
"ipv4" setting and "GENERAL" group
of active data
https://bugzilla.redhat.com/show_bug.cgi?id=997999
This commit adds two new functions for introspection users to get nameservers:
guint32 nm_ip6_config_get_num_nameservers (NMIP6Config *config)
const struct in6_addr *nm_ip6_config_get_nameserver (NMIP6Config *config, guint32 idx)
The existing function can't be used due to GObject introspection limitations:
const GSList *nm_ip6_config_get_nameservers (NMIP6Config *config);
https://bugzilla.redhat.com/show_bug.cgi?id=1056146
The change to per-domain log levels means that when setting just the
level, we need to re-set the log level for each domain (since it's the
"logging" bit array that actually determines what gets logged).
nm_logging_setup() was dealing correctly with domains=NULL, but not
domains="" (which is what happens when it is invoked with only a level
via D-Bus), so doing "nmcli gen log level DEBUG" would change the
"default" log level, but leave all of the domains still at their
previous level:
danw@laptop:NetworkManager> nmcli g log
LEVEL DOMAINS
INFO PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,IP4,IP6...
danw@laptop:NetworkManager> nmcli g log level DEBUG
danw@laptop:NetworkManager> nmcli g log
LEVEL DOMAINS
DEBUG PLATFORM:INFO,RFKILL:INFO,ETHER:INFO,WIFI:INFO,BT:INFO...
The sysctl values in the kernel (for those values for which
nm_platform_sysctl_get_uint() is currently used) are defined as s32.
Change nm_platform_sysctl_get_uint() to nm_platform_sysctl_get_int32()
and ensure, that a matching integer type is used thoroughly.
Signed-off-by: Thomas Haller <thaller@redhat.com>
