Avoid printing "nl_recvmsgs() error: (-33) Dump inconsistency detected,
interrupted". DUMP_INTR error is harmless for scan (see in code
comments).
Signed-off-by: Thomas Haller <thaller@redhat.com>
At critical times during the connection process, especially during
DHCP and EAPOL, the driver can increase the reliability of communication
in an attempt to increase the possibility of success. This could be
done by suppressing bluetooth for a short period, or locking in a low
(and thus more reliable) bitrate, or enforcing some other interference
protection. The 3.10 kernel added nl80211 support for this, so lets
use it if we can.
According to documentation, nl_rtgen_request() returns 0 on success.
Due to a bug (fixed upstream) in older libnl versions, nl_rtgen_request()
returns the number of bytes sent, which caused logging although
succeeding.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make it more clear, what the current monotonic_timestamp is and
what's it's offset to CLOCK_BOOTTIME.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This feature needs support from the kernel and libnl.
If there is no system support, NM acts as before, adding the
autoconf address as /128. It does so, to prevent the kernel
from adding a route for this prefix. With system support, we
add the address as /64 and set the flag IFA_F_NOPREFIXROUTE.
https://bugzilla.redhat.com/show_bug.cgi?id=1044590https://bugzilla.redhat.com/show_bug.cgi?id=1045118
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel adds a new capability to allow user space to manage
temporary IPv6 addresses. We need to detect this capability
to act differently, depending on whether NM has an older kernel
at hand.
This capability got introduced together when extending the
ifa_flags to 32 bit. So, we can check the netlink message,
whether we have such an nl attribute at hand.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel and libnl adds two new flags IFA_F_MANAGETEMPADDR
and IFA_F_NOPREFIXROUTE. Older versions of libnl do not recognize
this flag, so add a workaround to nm_platform_ip6_address_to_string()
to show "mngtmpaddr" and "noprefixroute", respectively.
Also, add function nm_platform_check_support_libnl_extended_ifa_flags()
that checks whether libnl supports extended ifa_flags that were
added recently.
Extended flags and the two ifa-flags above were added to libnl in close
succession.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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?)
