NetworkManager uses the sysctl value 'max_addresses' as the kernel does.
There is however a difference in what addresses are taken into account.
The kernel counts all addresses on the interface (including temporary,
private addresses and user configured ones).
NM instead only limits the number of public autoconf addresses to
'max_addresses'. This is because it is difficult for NM to count all
addresses (which can come from different sources) and it is not
necessarily a more logical behavior. Only be aware, that NM uses
the same config value as the kernel, but counts differently.
Especially, the kernel might reach the limit earlier then NM in the
presence of temporary addresses or addresses not from SLAAC.
Note, that the kernel uses 'max_addresses' only to limit public, autoconf
addresses. So this limit does not affect NM adding as many addresses as
it wants.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nl_socket_add_memberships expects a variadic list of int,
NULL is possibly defined as ((void *) 0) or 0L.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It is common that the file exists, but cannot be read
(Operation not supported). So, silence any error when
reading the phys_port_id file.
Signed-off-by: Thomas Haller <thaller@redhat.com>
find_master() does not (always) set the output parameters. Initialize
paramter to NULL before calling find_master().
Just introduced recently with commit 8123cd2410.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous version is not severely wrong, it is just be better
to treat connections whose retry block expires *now* as ready to
reconnect.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a master and at least one of its slaves were both autoconnect,
NMManager would end up creating two NMActiveConnections for the master
(one when the master itself is activated, and a second when the slave
is activated and calls ensure_master_active_connection(). (This
probably got broken when we changed it so ACs were created before
their devices.)
Fix this by checking for an existing master AC before creating one.
The 'mode' must be known from the beginning and changing it later on
would not be supported/meaningful. So, enforce this by setting the
property at construct time only.
https://bugzilla.redhat.com/show_bug.cgi?id=1034737
Signed-off-by: Thomas Haller <thaller@redhat.com>
There seems to be the possibility of a race while reading tun
properties from sysctl. In this case, when being unable to
read the properties at construction of NMDeviceTun, we retry
shortly after.
- let tun_get_properties() not log any errors and it
does not stop on the first error but tries to read all
the values. Also, it initializes all fields of the output
structure with a default value (NULL).
- hard code kernel flag #ifndef in header files. Even if the
flag IFF_MULTI_QUEUE is not defined at compile time of NM,
it could still be supported by the kernel (eg. when booting
a newer kernel then the installed kernel headers). Simply
hard code the value, this value is not ever going to change
anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1034737
Signed-off-by: Thomas Haller <thaller@redhat.com>
In some cases, an error when reading the sysctl value can be expected.
In this case, we want to suppress the error message
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the user is AddAndActivating a new network, the connection may not
have an NMSettingConnection yet, but we know that once it does, the
user will be authorized.
4f3a9cca6f stopped unescaping Team
configuration when reading ifcfg files due to inefficient algorithms
in svUnescape(). Unfortunately, since Team configuration is escaped
when written out, reading it in creates invalid configuration that
teamd rejects.
The pathological case was a 9MB invalid Team configuration. Since a
Team configuration will never, ever be that large, fix the issue by
warning the user or rejecting the configuration if it is over 20000
bytes in size (an arbitrary number). Thus svUnescape() will never
be called with huge strings, but the configuration is still unescaped.
https://bugzilla.redhat.com/show_bug.cgi?id=1051517
A gateway route can only be added, if there exists a device route
for that gateway. Therefore, nm_platform_ip4_route_sync() and
nm_platform_ip6_route_sync() has to add the device routes first,
before adding gateway routes.
Note: usually for all configured addresses, there is also a device
route for the subnet added by the kernel. This means, NM must first
configure the addresses before route_sync, so that these implicit device
routes already exist -- this is however already done correctly.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a route already exists that matches the network, prefix, gateway,
and metric of a route NM would like to add, don't try to overwrite
the route.
Unlike IP addresses, the kernel doesn't update the details, it
appears to completely replace that route, which might screw up
external tools that added the route originally.
One example of this is IPSec via openswan/libreswan. They add the
routes to the kernel upon connection, and if NM replaces those routes,
IPSec no longer works. While this may be due to kernel bugs or
bad handling of route replacement, there's no reason for NM to touch
routes that it wouldn't materially change anyway.
(yes, we could perhaps use NLM_F_REPLACE in add_kernel_object() only
when we really wanted to replace something, but why ask the kernel
to do the work when it's not required anyway?)
Two issues:
1) routes added by external programs or by users with /sbin/ip should not
be modified, but NetworkManager was always changing those routes' metrics
to match the device priority. This caused the nm_platform_ipX_route_sync()
functions to remove the original, external route (due to mismatched metric)
and re-add the route with the NetworkManager specified metric. Fix that
by not touching routes which came from the kernel.
2) Static routes (from persistent connections) that specified a metric were
getting their metric overwritten with the NetworkManager device priority.
Stop doing that.
Since the platform no longer defaults the metric to 1024, callers of
nm_platform_ip4_route_add() (like NMPolicy's default route handling)
must do that themselves, if they desire this behavior.
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
VPN services that use the kernel's IPSec stack (like OpenSwan/LibreSWAN)
obviously don't have a tunnel interface, so don't require one. If
those services provide Link-Local IPv6 DNS servers they simply won't
work, but perhaps we can filter those out later or warn about them.
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.
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).
