As an optimization, implement wifi_nl80211_get_freq() using the
GET_INTERFACE nl8022 command instead of the GET_SCAN dump.
The GET_SCAN dump can be over 10kB of data that the kernel has to build
and we have to parse. Additionally the GET_SCAN dump is not guaranteed
to contain the currently-connected BSS if there was no recent scan (30s),
or if the recent scan missed the beacon from the current BSS, or if the
recent scan was for a subset of channels/SSIDs/BSSIDs etc. and the last
full scan was already flushed. Scan results are flushed after (I think)
30 seconds or if a new scan has the flush flag set.
In IWD we do occasionally do partial scans (on a subset of channels or
for a specific SSID) with the flush flag. In that case the previous
wifi_nl80211_get_freq() logic would probably return 0.
It is not yet used, but it will be used to mark instances that
are not supposed to be configured in platform, because ACD is
either still pending of failed.
As one of the arguments in unsigned, the calculation is performed as
unsigned integers. That can actually lead to the wrong result. Fix it by
casting to the right (signed) types.
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
nm_utils_inet4_ntop() is public API of libnm. Also, it accepts a
%NULL buffer to use a static buffer. That is error prone and we
should not use such convenience behavior for our own code.
The kernel of Ubuntu 16.04 doesn't support IFLA_BR_VLAN_STATS_ENABLED.
If we want to run on such old kernels (which we probably do), we need to
detect that, and act accordingly.
Add nm_platform_kernel_support_get_full() to allow fetching the support
state without setting it to the compile time default.
Also, use g_atomic_int_get() to access _nm_platform_kernel_support_state
values. We should not access static variables without synchronization.
Better get it correct in any case than fast.
Older kernels may not support or send all bridge options in the netlink
message. In case the parameter is missing, set the default value.
Note that there may be future cases where we need to encode whether
the option is present or not. Currently we don't express that.
Older versions of iproute2 (Ubuntu 16.04) don't support all the requested
bridge options. We need to gracefully ignore a failure and try with our
own implementation.
While doing that, only set the command line arguments if they are
necessary (that is, if they requested value is not the default already).
Luckily, Ubuntu 16.04's kernel supports these properties just fine, so
we can avoid complicated compatibility code to cope with missing kernel
support. It's really just an iproute2 limitation and affects only the
tests.
This makes the macro more function like. Also, taking a pointer
makes it a bit clearer that this possibly changes the value.
Of course, it's not a big difference to before, but this
form seems slightly preferable to me.
