We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Next we will use siphash24() instead of the glib version g_direct_hash() or
g_str_hash(). Hence, the "nm-utils/nm-hash-utils.h" header becomes very
fundamental and will be needed basically everywhere.
Instead of requiring the users to include them, let it be included via
"nm-default.h" header.
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
Replace the usage of g_str_hash() with our own nm_str_hash().
GLib's g_str_hash() uses djb2 hashing function, just like we
do at the moment. The only difference is, that we use a diffrent
seed value.
Note, that we initialize the hash seed with random data (by calling
getrandom() or reading /dev/urandom). That is a change compared to
before.
This change of the hashing function and accessing the random pool
might be undesired for libnm/libnm-core. Hence, the change is not
done there as it possibly changes behavior for public API. Maybe
we should do that later though.
At this point, there isn't much of a change. This patch becomes
interesting, if we decide to use a different hashing algorithm.
In a later commit we'll add a new generic client function used by
nmcli and nmtui. nm-client-utils.c seems the right place for it, so
move the file to the base library that is used by both clients.
While at it, also put in that file some functions that will be needed
by nmtui.
So that the man page will display:
The permitted values are: NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_EUI64
(0) or NM_SETTING_IP6_CONFIG_ADDR_GEN_MODE_STABLE_PRIVACY (1).
instead of
The permitted values are: "eui64" or "stable-privacy".
since the latter is not useful at all for a int32 property.
Unfortunately the enum names are quite long and don't look very well
in a table, but that's another problem.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
DHCP timeout may now be explicitly disabled by setting the
ipv[4,6].dhcp-timeout options to "infinity".
This will set the DHCP timeout value to MAXINT32.
There are basically three options:
1) use a separate _get_fcn_gobject_dcb_priority() getter and
implement them as a new type _pt_gobject_dcb_priority.
2a) implement them as _pt_gobject_int and set nicks as value_infos,
repeating the nicks 3 times.
2b) like 2a, but use a macro to define how the DCB priority shall
behave at one place.
I think 1) is ugly. In the previous form, it also does not support
setting the property to "unset". We should implement properties as
types, and modify their behavior (by setting value_infos), instead
of implementing multiple, different types.
I slightly prefer 2b) over 2a) because it defines the behavior once,
but it's a bit harder to follow.
- Reduce duplicated code and implement the property according to
best-practice for integer types.
- Do not translate the output
- This way, the setter also supprts the nick names
No reason to, the other types are no less likely. Quite the contrary, if
the user specifies a GSM APN we're sure to use a DUN profile.
$ ./clients/cli/nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 apn internet
$ nmcli c show bluetooth-1 |grep bluetooth.type
bluetooth.type: panu
^^^^ not cool
Unbreaks Bluetooth DUN. Probably broken with the nm-meta-setting-desc
refactor, hence the Fixes tag. I didn't actually check.
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm
Error: 'apn' argument is required.
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm apn internet
Error: invalid <setting>.<property> 'apn'.
$
This is where it starts to get sad ^
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm gsm.apn internet
Error: invalid or not allowed setting 'gsm': 'gsm' not among [connection, bluetooth, bridge, ipv4, ipv6, proxy].
$
This is where it gets obvious what went wrong ^
Fixes: b5c8622ad3
When the property is set, it specifies the device on which PPPoE is to
be started. The ppp interface will be named as the
connection.interface-name property.
When the property is not set the previous behavior will be retained,
i.e. the PPPoE connection will be started on connection.interface-name
and the PPP interface will have a random name.
Software devices don't have a permanent hardware address and thus it
doesn't make sense to enforce the 'fake' (generated) permanent one
when cloned-mac-address=permanent. Also, setting the fake permanent
address on bond devices, prevents them from inheriting the first slave
hardware address, so let's just skip the setting of MAC when
cloned-mac-address=permanent and there is no real permanent address.
https://bugzilla.redhat.com/show_bug.cgi?id=1472965
