When the operation is cancelled, we must not touch user_data. Note that
NM_POLICY_GET_PRIVATE() theoretically doesn't dereference the pointer
(does it?) but doing pointer arithmetic on a dangling pointer is a very
ugly thing to do.
And of course, the memleak.
Fixes: 5c716c8af8
Fixes: a2cdf63204
The default timeout in dhclient is 60 seconds; if a lease can't be
obtained during such interval, dhclient sends to NM a FAIL event and
then the IP method fails.
Thus, even if user specified a greater dhcp-timeout, NM terminated
DHCP after 60 seconds. Fix this by passing an explicit timeout to
dhclient.
(cherry picked from commit 82ef497cc9)
The default timeout in dhclient is 60 seconds; if a lease can't be
obtained during such interval, dhclient sends to NM a FAIL event and
then the IP method fails.
Thus, even if user specified a greater dhcp-timeout, NM terminated
DHCP after 60 seconds. Fix this by passing an explicit timeout to
dhclient.
The PMF property is an GEnum, not GFlags. We only have the GObject
property NM_SETTING_WIRELESS_SECURITY_PMF as plain integer type
to allow for future extensions.
But commonly, enums are signed int, while flags are unsigned. Change
the property to be signed for consistency.
Now that we have a PMF connection property, get rid of the previous
code to globally enable/disable PMF and use the 'ieee80211w'
configuration option for each configured network when the supplicant
supports it.
py-kickstart writes this out. Okay -- we don't care on read and it makes
sense when there actually are addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=1445414
(cherry picked from commit aa50dfc236b3806c6d7161cdea450655a1268f0d)
For example, if you want to test whether a value is present and
reset it to a different value (only if it is present), it would
be reasonable to do
if (svGetValue (s, key, &tmp)) {
svSetValue (s, key, "new-value");
g_free (tmp);
}
Without this patch, you could not be sure that key is not
set to some inparsable value, which svWriteFile() would then
write out as empty string.
Have invalid values returned by svGetValue() as empty string.
That is how svWriteFile() treats them.
(cherry picked from commit 6470bed5f1ad25e20df14b333f1b083c9b390ece)
For example, if you want to test whether a value is present and
reset it to a different value (only if it is present), it would
be reasonable to do
if (svGetValue (s, key, &tmp)) {
svSetValue (s, key, "new-value");
g_free (tmp);
}
Without this patch, you could not be sure that key is not
set to some inparsable value, which svWriteFile() would then
write out as empty string.
Have invalid values returned by svGetValue() as empty string.
That is how svWriteFile() treats them.
The dad_counter is hashed into the resulting address. Since we
want the hashing to be independent of the architecture, we always
hash 32 bit of dad_counter. Make the dad_counter argument of
type guint32 for consistency.
In practice this has no effect because:
- for all our (current!) architectues, guint is the same as
guint32.
- all callers of nm_utils_ipv6_addr_set_stable_privacy() keep
their dad-counter argument as guint8, so they never even pass
numbers larger then 255.
- nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter
further against RFC7217_IDGEN_RETRIES.
(cherry picked from commit 951e5f5bf8)
https://tools.ietf.org/html/rfc7217 says:
The resulting Interface Identifier SHOULD be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an
address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been
generated, this situation SHOULD be handled in the same way as
the case of duplicate addresses (see Section 6).
In case of conflict, this suggests to create a new address incrementing
the DAD counter, etc. Don't do that. If we generate an address of the
reserved region, just rehash it right away. Note that the actual address
anyway appears random, so this re-hashing is just as good as incrementing
the DAD counter and going through the entire process again.
Note that now we no longer generate certain addresses like we did
previously. But realize that we now merely reject (1 + 16777216 + 128)
addresses out of 2^64. So, the likelyhood of of a user accidentally
generating an address that is suddenly rejected is in the order of
10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
extreeeemely unlikely.
Also, the whole process is anyway build on the idea that somebody else
might generate conflicting addresses (DAD). It means, there was always
the extremely tiny chance that the address you generated last time is
suddenly taken by somebody else. So, this change appears to a user
like these reserved addresses are now claimed by another (non existing)
host and a different address gets generated -- business as usual, as
far as SLAAC is concerned.
(cherry picked from commit f15c4961ad)
The dad_counter is hashed into the resulting address. Since we
want the hashing to be independent of the architecture, we always
hash 32 bit of dad_counter. Make the dad_counter argument of
type guint32 for consistency.
In practice this has no effect because:
- for all our (current!) architectues, guint is the same as
guint32.
- all callers of nm_utils_ipv6_addr_set_stable_privacy() keep
their dad-counter argument as guint8, so they never even pass
numbers larger then 255.
- nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter
further against RFC7217_IDGEN_RETRIES.
https://tools.ietf.org/html/rfc7217 says:
The resulting Interface Identifier SHOULD be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an
address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been
generated, this situation SHOULD be handled in the same way as
the case of duplicate addresses (see Section 6).
In case of conflict, this suggests to create a new address incrementing
the DAD counter, etc. Don't do that. If we generate an address of the
reserved region, just rehash it right away. Note that the actual address
anyway appears random, so this re-hashing is just as good as incrementing
the DAD counter and going through the entire process again.
Note that now we no longer generate certain addresses like we did
previously. But realize that we now merely reject (1 + 16777216 + 128)
addresses out of 2^64. So, the likelyhood of of a user accidentally
generating an address that is suddenly rejected is in the order of
10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
extreeeemely unlikely.
Also, the whole process is anyway build on the idea that somebody else
might generate conflicting addresses (DAD). It means, there was always
the extremely tiny chance that the address you generated last time is
suddenly taken by somebody else. So, this change appears to a user
like these reserved addresses are now claimed by another (non existing)
host and a different address gets generated -- business as usual, as
far as SLAAC is concerned.
Fixes a crash where the default DNS domain to be announced together with the
prefixes to be delegated is updated at the same time the device is being
unrealized.
https://bugzilla.redhat.com/show_bug.cgi?id=1425818
(cherry picked from commit 3e076cf8b1)
Fixes a crash where the default DNS domain to be announced together with the
prefixes to be delegated is updated at the same time the device is being
unrealized.
https://bugzilla.redhat.com/show_bug.cgi?id=1425818
NMDeviceGeneric:check_connection_compatible() doesn't check for a
matching interface name. It relies on the parent implementation to
do that.
The parent implementation calls nm_manager_get_connection_iface().
That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has
no factory. Maybe this imbalance of having no factory for the Generic device
is wrong, but usually factories only match a distinct set of device
types, while the generic factory would handle them all (as last resort).
Without this, activating a generic connection might activate the
wrong interface.
(cherry picked from commit 3876b10a47)
NMDeviceGeneric:check_connection_compatible() doesn't check for a
matching interface name. It relies on the parent implementation to
do that.
The parent implementation calls nm_manager_get_connection_iface().
That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has
no factory. Maybe this imbalance of having no factory for the Generic device
is wrong, but usually factories only match a distinct set of device
types, while the generic factory would handle them all (as last resort).
Without this, activating a generic connection might activate the
wrong interface.
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
(cherry picked from commit f04bf45e84)
We have unit tests for writing and re-reading ifcfg file. Those
tests compare whether a file can be successfully read and is
semantically identical.
However, there were no tests that a certain output is written in
a stable format. We aim not to change the output of what we write.
For that, add tests to not only check the semantic of the written
ifcfg file, but their bits and bytes.
Some future changes may well intentionally change the current
output. That will require to update the expected result files
and can be done via
NMTST_IFCFG_RH_UPDATE_EXPECTED=yes src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh
Note that alias, route, and key files are not checked.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1445414
Before refactoring nmcli recently, field names were marked for translation.
Note that for the property names, marking them had no effect as only
plain strings can be marked with N_().
Note how --fields are also an input argument. The input should be
independent of the locale and not translated. Likewise, when printing
the header names, they should not be translated to match the --fields
option.
$ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25
GENERAL.GERÄT: enp0s25
Drop the translation marks.
