We require a network-id. Assert that it is set.
Also, we encode the stable-id as uint8. Thus, add
an assertion that we don't use more then 254 IDs.
If we ever make use of stable-type 255, we must extend
the encoding to allow for more values. The assertion
is there to catch that.
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
mac-address-randomization as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
We set a dedicated route to reach the VPN gateway only if the parent
device has a gateway. If the parent device doesn't have a gateway (for
example in case of GSM connections) and the VPN gets the default
route, the VPN gateway will be contacted through the VPN itself, which
obviously doesn't work.
Set up a device route if the parent device doesn't provide a gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1403660
It results in a rather confusing behavior:
# nmcli c modify wifi \
802-1x.private-key /etc/pki/themostsecret.key \
802-1x.private-key-password verystrong
Error: failed to modify 802-1x.private-key: private key
password not provided.
Moreover, the user might have a good reason for not specifying it on a command
liue and it's not strictly required anyway -- we'll do fine if we don't verify
a private key at addition time.
It's not the job of keyfile writer to enforce certain settings. A
%NULL GBytes property is shall be treated distinct from a byte array
with zero length.
The NMSetting may or may not reject such settings as invalid during
verify() or mangle them during normalize(). But reader/writer should
just serialize every property as-is.
We use write_array_of_uint() for G_TYPE_ARRAY. In practice, only
NMSettingDcb has any properties of this type.
Furthermore, all valid values are either gboolean or guints of
restricted range. Thus, no valid NMSettingDcb should violate the
range check.
Same for reader.
It's really ugly to blindly use uint-list reader for G_TYPE_ARRAY.
Especially, because certain G_TYPE_ARRAY properties of NMSettingDcb
are actually arrays of gboolean, which only ~accidentally~ has the same
memory layout as guint.
No longer use a regex to pre-evaluate whether @tmp_string looks
like a integer list. Instead, parse the integer list ourself.
First, drop the nm_keyfile_plugin_kf_has_key() check.
Note that this merely verifies that such a key exits. It's rather
pointless, because get_bytes() is only called for existing keys.
Still, in case the check would actually yield differing results
from the following nm_keyfile_plugin_kf_get_string(), we want to
act depending on what nm_keyfile_plugin_kf_get_string() returns.
Note that nm_keyfile_plugin_kf_get_string() looks up the key, alternatively
fallback to the settings alias. Then, GKeyFile would parse the raw keyfile
value and return it as string.
Previously, we would first decide whether @tmp_string look like a integer list
to decide wether to parse it via nm_keyfile_plugin_kf_get_integer_list().
But note that it's not clear that nm_keyfile_plugin_kf_get_integer_list()
operates on the same string as nm_keyfile_plugin_kf_get_string().
Could it decide to return different strings based on whether such
a key exists?
E.g. when setting "802-11-wireless.ssid=foo" and "wifi.ssid=60;" they
clearly would yield differing results: "foo" vs. [60].
Ok, probably it is not an issue because we call first
nm_keyfile_plugin_kf_get_string(), decide whether it looks like a
integer list, and return "foo" right away.
This is still confusing and relyies on knowledge about how the value
is encoded as string-list.
Likewise, could our regex determine that the value looks like a integer
list but then the integer list is unable to parse it? Certainly that can
happen for values larger then 255.
Just make it consistent. Get *one* @tmp_string. Try (manually) to
interpret it as string list, or bail using it as plain text.
Also, allow returning empty GBytes arrays. If somebody specifies an
empty list, it's empty. Not NULL.
The only implementations were there for tracking the parent device.
That is now donw via nm_device_parent_*(), parent_changed_notify()
and _parent_notify_changed().
Multiple subclasses have a parent/link interface (NMDeviceIPTunnel,
NMDeviceVlan). Tracking the parent interface properly is midly
complicated to get right. So, instead of repeating it in each
subclass, track it in the parent device.
Move the updating/setting of the ip-ifindex/ip-iface to one place.
Properties should be for the most part immutable/read-only, and only
at particular places modified. That way, it's easier to track who
changes a property.
Also, add a logging line with "ip-ifname" prefix.
Most implementations of realize_start_notify() do the same
for link_changed().
Let NMDevice's base implementation of realize_start_notify() call
link_changed() -- which by default does notthing. This allows subclasses
to only overwrite link_changed().
Instead of overwriting constructed(), update the s390 subchannels via
realize_start_notify(). This makes more sense and is also more similar
to what other device implementations do.
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
