Also change the signature of the NM_SUPPLICANT_INTERFACE_STATE signal,
to have three "int" type arguments. Thereby also fix the subscribers
to this signal that wrongly had type guint32, instead of guint
(which happens to be the same underlying type, so no real problem).
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00021.html
(cherry picked from commit 5a03de7051)
Cache the value for accessing the GObject property
NM_DEVICE_WIFI_SCANNING.
Re-evaluating the property every time by checking the
supplicant interface is ugly because it might change
under the hood. It should only change if (and only if)
we emit a notify changed signal.
Also, avoid accessing
nm_supplicant_interface_get_scanning (priv->sup_iface)
without checking whether priv->sup_iface is not NULL.
(cherry picked from commit 4e84472b47)
When we dump a list of APs, determine one timestamp for "now",
instead of re-evaluating it every time.
This ensures that all APs are printed with the same understanding
of the current timestamp.
(cherry picked from commit 5e4d13271c)
LOGD_WIFI_SCAN is there to avoid flodding the log with continous scan
results. It should not be used for messages related to scheduling scan
requests.
This is especially important, because LOGD_WIFI_SCAN domain is not
included in LOGD_DEFAULT.
(cherry picked from commit d5657d003c)
The _LOGD() macros of NMDeviceWifi print a logging context for each
line, that is, they add a prefix with the device name.
Replace nm_wifi_ap_dump() by nm_wifi_ap_to_string() and let device
log a message about the AP.
Also, update the format for printing the AP. Now, all fields are
separated by space.
(cherry picked from commit d98fa31ddd)
- no longer bother clearing .state and .reason when the .id
field is unset. The fields just don't matter and no user
accesses these fields when the glib source id is not set.
- unify logging and give them all a prefix "queue-state[%s, %s, %u]: ".
- drop nm_device_queued_state_peek(), it only had one caller,
thus inline the trivial check.
- make nm_device_queued_state_clear() a static function
queued_state_clear()
- rename queued_set_state() to queued_state_set().
(cherry picked from commit 96b167cd97)
Reorder code to be like in other source files:
- first includes and generic defines
- then various helper structs
- then GObject related declarations, with first signal and property
enums, then the private data, then the G_DEFINE_TYPE() itself.
- finally, forward declarations for functions.
(cherry picked from commit f97d8b86fb)
We don't want to waste a full "int" size to store the @hw_addr_type
in NMDevicePrivate. Previously, that was hacked around by using guint8.
Now, instead use a bitfield which has the right type.
(cherry picked from commit cac0738723)
These two structs are only used at exactly one place: as the type
for a field in NMDevicePrivate.
Having additional structs (that are only used at one place) only
add noise. Also, there are already prior-acts of using unnamed
structs in NMDevicePrivate in case of structs that only serve
to group/namespace a set of fields.
(cherry picked from commit 5151a6071f)
All callers either use a static @action argument or keep a clone
of the string that lives as long as the action is pending. So,
save cloning the string.
(cherry picked from commit 3bc1e02adf)
While we still recheck-available, we want to queue a pending action to block
startup-complete. However, we have to queue that before removing the pending
action for "wait for supplicant".
<debug> [...] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant'
<info> [...] manager: startup complete
<debug> [...] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
(cherry picked from commit 252e95c113)
Startup-complete means that all devices have settled in a state
and no further activation is pending. When we have a recheck-available
scheduled, we clearly should not yet declare startup-complete.
Add a new pending-action "recheck-available" to avoid:
<info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready
<debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant'
<info> [1485520408.3920] manager: startup complete
<debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
(cherry picked from commit 11744b090e)
grep-ing for '\<scanning\>' yields 42 hits under src. But only 2 are actual
references to the "scanning" GObject property of NMDeviceWifi.
Use a #define with a unique name where we mean NMDeviceWifi's property.
(cherry picked from commit 95a95b3e48)
The -Wimplicit-fallthrough=3 warning is quite flexible of accepting
a fall-through warning.
Some comments were missing or not detected correctly.
Thereby, also change all other comments to follow the exact
same pattern.
(cherry picked from commit 7c6c8f0d8b)
The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
(cherry picked from commit 9ae5e6a54d)
Previously, we would have different functions like
- nm_match_spec_device_type()
- nm_match_spec_hwaddr()
- nm_match_spec_s390_subchannels()
- nm_match_spec_interface_name()
which all would handle one type of match-spec.
So, to get the overall result whether the arguments
match or not, nm_device_spec_match_list() had to stich
them together and iterate the list multiple times.
Refactor the code to have one nm_match_spec_device()
function that gets all relevant paramters.
The upside is:
- the logic how to evaluate the match-spec is all at one place
(match_device_eval()) instead of spread over multiple
functions.
- It requires iterating the list at most twice. Twice, because
we do a fast pre-search for "*".
One downside could be, that we have to pass all 4 arguments
for the evaluation, even if the might no be needed. That is,
because "nm-core-utils.c" shall be independend from NMDevice, it
cannot receive a device instance to get the parameters as needed.
As we would add new match-types, the argument list would grow.
However, all arguments are cached and fetching them from the
device's private data is very cheap.
(cherry picked from commit b957403efd)
After commit 553717bb1c ("device: don't set ip4_state=IP_FAIL for
ipv4.method=disabled"), we commit an empty IPv4 configuration when
IPv4 is disabled. This means that it's not necessary anymore to call
_commit_mtu() because the MTU will be set in
ip4_config_merge_and_apply().
(cherry picked from commit 714b18dcf7)
After commit 22e8af6242 ("device: set a per-device default MTU on
activation") we explicitly set the VLAN MTU to 1500 if not overridden
by user settings. This has the advantage that the MTU is set to a
predictable value, while before it could have different values
depending on when the interface was created (for example, the
interface would get a 1500 MTU if created during boot, or would
inherit the parent's MTU if activated manually).
However, a better default value is the MTU of the parent interface
which is in most cases what the user wants. This value was the default
before commit 22e8af6242 for manually activated connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1414186
(cherry picked from commit 7dde8d8106)
Basically to silence gcc that is not smart enough to understand how does
.initialized and .value relate.
src/devices/nm-device.c: In function '_commit_mtu':
src/devices/nm-device.c:6754:15: error: 'ip6_mtu_sysctl.value' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (ip6_mtu && ip6_mtu != _IP6_MTU_SYS ()) {
^
(cherry picked from commit 7ce805d49d)
This allows a user to restore the previous behavior where NetworkManager
would not reconfigure the MTU during device activation, if no MTU is
available (commit "22e8af6 device: set a per-device default MTU on
activation").
Well, not exactly. The previous behavior was to use per-connection
configuration, then DHCP provided value, or finally leave the MTU
unspecified.
Now, we prefer a per-connection configuration, followed by a global
connection default. If "ethernet.mtu=0", the MTU is left unspecified.
In absense of a global connection default, the value from DHCP is used
or finally a per-device-type default. That is effectively 1500 for most
types, except for infiniband where the MTU is still left unspecified.
Add code to nm-device-macsec.c to support the creation of macsec
connection. Most of the code for controlling wpa_supplicant is copied
from nm-device-ethernet.c and probably could be consolidated in some
ways.
In absence of an explicit MTU (either via user configuration, PPP or
DHCP), set a default MTU on activation that depends on the device type.
We only want to do that on the very first call to _commit_mtu(). Later
calls (for example in response to new DHCP leases) skip over this step.
This means, on activation the MTU will always be reset to a sensible
value instead of preserving whatever was left from a previous
configuration.
This does not cover setting the MTU from the VPN plugin :(
When you have a connection with "ethernet.mtu=0 (auto)", the MTU is not set
during activation. That means, the effective MTU depends on the previous
MTU configuration of the device. Which in turn, depends on the
previously active connection, as we don't reset the MTU on deactivation.
Restore the previous MTU on deactivation iff NetworkManager changed
the MTU during device activation.
Don't have this mtu_desired variable. All the data is readily available
without redundancy. E.g. the applied-connection contains everything
we need to know. Just get it as needed.
Also drop apply_mtu_from_config(). It didn't take into account
the MTU settings beside NMSettingWired.
Also, no longer merge the NM_IP_CONFIG_SOURCE_USER MTU value into
priv->ip4_config. NMIP4Config now only tracks the MTU from the various
non-user-config sources, but the user config is no longer merged back
into the composite.
The problem is that the bridge's MTU cannot be larger then the slaves'.
Configuring such a setting results in an error being logged and the
activation proceeds (without applying the desired MTU).
Unclear how to fix that best.
Instead of overwriting ip4_config_pre_commit(), add a new function
get_mtu().
This also adds a default value in case there is no user-configuration.
This will allow us later to reset a default MTU based on the device
type.
The field priv->mtu should contain what is actually configured
on the device, as that field is also exposed on D-Bus as NM_DEVICE_MTU
property.
That shall be handled distinct from what we want to configure as
MTU on the device.
Refactor the handling of MTU with a new functoin _set_mtu() which looks
at the desired paramters and compares it with what is configured (in
platform and sysctl). Then it makes a decision what to configure.
Mark priv->mtu/priv->ip_mtu/ priv->ip6_mtu as const to highlight the
places that explicitly set their mutable aliases priv->mtu_/
priv->ip_mtu_/priv->ip6_mtu_.
Also, NM_DEVICE_MTU property is read-only. It cannot be set
via g_object_set().
Also, clear priv->mtu in nm_device_unrealize().
