The wireless-security setting has a 'wep-key-type' property that is
used to specify the WEP key type and is needed because some keys could
be interpreted both as a passphrase or a hex/ascii key.
The ifcfg-rh plugin currently stores the key type implicitly: if
wep-key-type is 'passphrase' it uses the KEY_PASSPHRASE%d variable, if
it's 'key' the KEY%d variable and when it's 'unknown' it uses either
variables depending on the detected type (preferring 'key' in case
both are compatible).
This means that some connections will be read differently from how
they were written, because once the KEY (or KEY_PASSPHRASE) is read
there is no way to know whether the 'wep-key-type' property was 'key'
(or 'passphrase') or 'unknown'.
Fix this by persisting the key type explicitly in the file. The new
variable is redundant in most cases because the variables used for
keys also determine the key type.
https://bugzilla.redhat.com/show_bug.cgi?id=1518177
$ nmcli con add type wifi ifname wlan0 \
wifi-sec.key-mgmt none \
wifi-sec.wep-key0 $ascii_key \
ssid <TAB>
completes the line with:
"Info:\ WEP\ key\ is\ guessed\ to\ be\ of\ '2\ \(passphrase\)'"
The environment warning function should not emit warning when
completing arguments.
Until now the ifcfg-rh plugin merged the values of 'ipv4.dns-options'
and 'ipv6.dns-options' and wrote the result to the RES_OPTIONS
variable. This is wrong because writing a connection and reading it
back gives a different connection compared to the original.
This behavior existed since when DNS options were introduced, but it
became more evident now that we reread the connection after write,
because after doing a:
$ nmcli connection modify ethie ipv4.dns-options ndots:2
the connection has both ipv4.dns-options and ipv6.dns-options set. In
order to delete the option, an user has to delete it from both
settings:
$ nmcli connection modify ethie ipv4.dns-options "" ipv6.dns-options ""
To improve this let's use different variables for IPv4 and IPv6. To
keep backwards compatibility IPv4 still uses RES_OPTIONS, while IPv6
uses a new IPV6_RES_OPTIONS variable.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
Commit 6a4af482f0 ("nmtui: always create ethernet settings for VLAN
and wireless security for wifi.") changed nmtui to always add the
wireless security setting to the new connection, but without
initializing it. This leads to a crash that was fixed in 40fcf67a84
("tui: fix crash creating Wi-Fi connection").
There is an additional bug: connections without authentication can't
be saved because the wireless security setting has uninitialized
fields.
To fix this, revert both patches (the first partially) because the
previous code did the right thing as it added the setting only when
needed.
Fixes: 6a4af482f0https://bugzilla.redhat.com/show_bug.cgi?id=1518167
The matching works fuzzy and is not reliable. That is why we store
which connection should be assumed after restart in the state file
of NetworkManager.
In that case, we don't need to do a full check (with the possibility
of a false-reject). Just check for the minimum required properties:
the type and slave-type.
Yes, if the user modifies the connection while restarting NM, then
we might wrongly assume a connection that no longer would match.
But NM should not read minds, it should do as indicated.
Waiting for carrier on startup is probably the same times that carrier
needs, e.g. on an MTU change. Use the same timing.
Note, that as carrier-wait-timeout is no configurable, this
configuration applies to both -- as the manual page already
claims to do.
$ nmcli connection down p
path
Connection 'p' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
Don't do completion when not requested.
When activation of the connection fails with no-secrets, we block
autoconnect due to that. However, NMPolicy also unblocks such
autoconnect, whenever a new secret-agent registers. The reason
is obviously, that the new secret-agent might be able to provide
the previously missing secrets.
However, there is a race between
- making the secret request, failing activation and blocking autoconnect
- new secret-agent registers
If the secret-agent registers after making the request, but before we
block autoconnect, then autoconnect stays blocked.
[1511468634.5759] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
[1511468634.5772] device (wlp4s0): No agents were available for this request.
[1511468638.4082] agent-manager: req[0x55ea7e58a5d0, :1.32/org.kde.plasma.networkmanagement/1000]: agent registered
[1511468638.4082] policy: re-enabling autoconnect for all connections with failed secrets
[1511468664.6280] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
[1511468664.6287] policy: connection 'tuxmobil' now blocked from autoconnect due to no secrets
Note the long timing between making the secret request and the
activation failure. This race already existed before, but now with
WPS push-button method enabled by default, the duraction of the
activation is much longer and the race is easy to hit.
https://bugzilla.gnome.org/show_bug.cgi?id=790571
We want to only check for autoconnect all, if something happend that
makes it possible that we can autoconnect now (while we couldn't
previously).
It's not a real problem to check more often then strictly necessary.
But add a check to rule out a few false-positives to avoid the
overhead of checking all devices for autoconnect.
reset_autoconnect_all() as two callers with only_no_secrets=FALSE:
- sleeping_changed() when NM returns from sleep.
- when device changes to state DISCONNECTED with reason
CARRIER.
In both cases, this should not overwrite a previous decision by
the user that the connection should not autoconnect.
schedule_activate_all() is expensive. It iterates over all devices, and asks
them to autoactivated (which might involve iterating over all connections for
each device). Avoid it if nothing changed.
Extend the enum and API to use flags for the blocked reasons.
A connection is blocked from autoconnect if it has any reason
set.
There is no behavioral change in this patch beyond that, because
where we previously would set blocked-reason NONE, we would still
clear all flags, and not only a particular one.
Later of course, we want to set and clear individual flags
independently.
NMPolicy printed
policy: connection 'a' failed to autoconnect; 1 tries left
settings-connection[0x55a485553b60,ab9f3891-3420-335e-89da-f14c1b94c540]: autoconnect: retries set 0
That is, it claimed there was one more try, when in fact there wasn't.
It's not ever going to change(*), and NMPolicy calls reset() a lot.
No need to lookup the configuration in the GKeyFile every time.
(*) per NMConfigData instance. The config may be reloaded, in which
case NMConfig creates a new NMConfigData instance, but the NMConfigData
instance itself is immutable.
NMPolicy would at various time call nm_settings_connection_autoconnect_retries_reset()
followed by nm_settings_connection_autoconnect_retries_get().
This resulted in two logging messages, first to indicate that the value
was unset, and then reset it to the value from configuration. While that
is correct, it causes a lot of verbose logging. Especially for all connections
which autoconnect retry counter didn't actually change.
The advantage of that was, that we only loaded the actual value when we
need it the first time (during get()). That means, the user could reload
the configuration, and the value would be loaded and cached at a later
pointer.
However, the duplicate logging was annoying, but we still want to see
a message about the resetting.
So, now during reset load the value setting from NetworkManager.conf
and set it right away. Skip the intermediate UNSET value. In most
cases nothing changed now, and we don't log anything for most
connections.
Our GError codes are mostly meaningless, only the message is interesting.
And our messages should anyway be unique, so that one could understand
which was the corresponding error code (by inspecting the source code).
While at it, use gs_free_error.
Note that for the
if (nm_device_state_reason_check (reason) == NM_DEVICE_STATE_REASON_NO_SECRETS)
case we no longer do the
if (nm_settings_connection_autoconnect_retries_get (connection) == 0)
check. But that is fine, because we only skip schedling a reset_connections_retries()
action. But note, that that previously we also would never actually
scheudle a new timeout, because
- either nm_settings_connection_autoconnect_retries_get (connection) != 0
- or the retries count was zero, in which case we already have a
reset_connections_retries action pending (from the time when we
set it to zero.
So, there is no change in behavior at all except dropping of a redundant
logging line.
NMSettingsConnection has 3 properties that are related to autoconnect:
- autoconnect_retries
- autoconnect_blocked_until
- autoconnect_blocked_reason
autoconnect_blocked_reason is entirely independent from the other two.
A connection have have autoconnect blocked via a blocked-reason, but the
retry count is not affected by that. The retry count is an independent
mechanism, that may additionally prevent autoconnect.
However autoconnect_retries and autoconnect_retries_blocked_until are
strongly related. The latter is set if and only if autoconnect_retries is
at zero.
Rename to reflect that better.
