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.
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>
Similar to "core: respect connection user permissions for activation/deactivation",
if a master connection is being activated because a slave connection requested
it, ensure that the user requesting the master connection is allowed to
activate it.
This appears to be a bug since the original 0.9.0 release when
connection permissions were implemented.
If all the following are true:
- the user is local (as determined by systemd or ConsoleKit)
- the user has been given the NETWORK_CONTROL PolicyKit permission
- the user is not listed in the connection's permissions
- the user knows the D-Bus object path of a connection which they
have no permissions for
then that user may activate/deactivate connections that are not
visible to that user as determined by the connection permissions.
Fix that by ensuring that these operations check whether the user
has permission.
These operations are *not* affected, and have always checked user
permissions before allowing the operation:
- modifying any connection details
- requesting any secrets or passwords for the connection
- deleting the connection
When receiving an IPv4/IPv6 address from the kernel, platform set the
timestamp to an invalid value before. The address timestamp must be set
to *now*, because the lifetime and preferred arguments are counting from
now.
Signed-off-by: Thomas Haller <thaller@redhat.com>
update_system_hostname() was bailing out if (there is no IP4 config or
the IP4 config has no addresses) AND (there is no IP6 config or the
IP6 config has no addresses), but it would then hit an assertion and
crash if there was a valid IP6 config along with an IP4 config with no
addresses. Fix that and get rid of some redundancy.
Sort of pointed out by Coverity.
Now UPDATED_BY_USER signal gets emitted immediately after the connection
is updated, rather then only after it is successfully saved.
This means, that the signal will be emitted earlier then before (right
after changing the connection, but before it gets commited).
Furthermore, the signal will also be emitted for connections that
get changed but are not to be saved.
Currently, the only subscriber to this signal is NMSettings
(default_wired_connection_updated_by_user_cb), which should be fine with
this change of semantics (even better).
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
- use a more efficient implementation for prefix_to_netmask
- fix netmask_to_prefix to behave consistently in case of
invalid netmask
- remove unused duplicated functions from NetworkManagerUtils.c
- add test functions
Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771
For now, ignore them, as libnl does not support IPv6 PtP addresses
and returns an error. In the future perhaps we'll want to add a host
route for the peer instead of using the point-to-point address.
Move DHCP_SEND_HOSTNAME parsing out of the check for DHCP_HOSTNAME so that
users can disable NM sending the system hostname to the DHCP server when
DHCP_HOSTNAME is not defined.
NMAgentManager was supposed to be trying multiple secret agents on any
error except UserCanceled, but due to a botched last-minute rewrite,
it was actually doing the reverse.
nm_logging_level_to_string() returned a const string, but
nm_logging_domains_to_string() returned a malloced one, which was
getting leaked in impl_manager_get_logging(). Fix this by making them
both malloced, and freeing as needed.
If the command line or NetworkManager.conf mentions a non-existent
domain, just print a warning and ignore it. That way if you switch to
using an older NM that doesn't have that domain, it will still work.
