The parser is reworked, and this line could be wrongly parsed
because it starts with " * value:" which could be misinterpreted
as a tag. It actually won't be parsed wrongly and is not parsed
wrongly now. Still, avoid this potential ambiguity by breaking
the line differently.
If teamd crashes, we restore it. That's very nice, but if it really
crashed then it left ports attached and the slave connections are not
going to fail and the port configuration (e.g. priority or link watcher) in
teamd's memory will be gone.
This will restore the port configuration when the teamd connection is
re-established. This probably also fixes a race where a slave connection
would be enslaved (only possible externally and manually?) while we
didn't establish a connection to teamd yet. We'll just send the port
configuration in once're connected.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
Add option to set ofport_request when configuring ovs interface. When
connection with ofport_request configured is activated ovsdb will first
try to activated on the port set by ofport_request.
the .h.in file is not formatted by our nm-code-format.sh
file. It also contains .in template parameters that the
formatting would destroy.
Still, follow our current style and reformat the parts manually.
It's between "stop" and "clean". It removes the container,
but keeps the container images. This is to fast restart without
rebuilding the container (image).
Because, why not?
The client side determines the UUID, so there is no security implication
by letting the nmcli user explicitly choose it.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Connection 'x' (6965f79c-4424-4918-98e8-3c0982434011) successfully added.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Error: Failed to add 'x' connection: a connection with this UUID already exists
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434012
Error: failed to modify connection.uuid: the property can't be changed.
It is useful to modify the UUID in offline mode. Otherwise, it's
cumbersome to clone a profile, because the cloned profile will
have the same UUID (and NetworkManager cannot load them both
at the same time).
umask 077
nmcli --offline connection modify \
connection.id profile2 \
connection.uuid new \
< /etc/NetworkManager/system-connections/profile1.nmconnection \
> /etc/NetworkManager/system-connections/profile2.nmconnection \
The doctext doesn't actually work for `man nm-settings-nmcli`. The
generation of our docs is still an incomprehensible mess that needs
fixing.
We really should not pass bogus values "1, 0" to g_set_error().
As we don't care about a particular error code, use
NM_UTILS_ERROR_UNKNOWN.
While at it, use nm_utils_error_set() everywhere.
Try to first use a stack allocated buffer for the temporary string.
Only if the data is too large, NMStrBuf will automatically grow
the buffer on the heap.
In many cases, this buffer will be large enough, and we can avoid the
heap allocation.
- instead of g_str_hash()/g_direct_hash(), use our own functions
nm_str_hash()/nm_direct_hash(). Those use siphash24 with a random
seed.
- don't pass g_direct_equal() to GHashTable. When omitting the equal
function, it falls back to direct pointer comparison, which is likely
faster. In any case, it's consistent to not use g_direct_hash()
when using pointer equality.
- instead of g_int_hash()/g_int64_hash()/g_double_hash(), use
our nm_pint_hash()/nm_pint64_hash()/nm_pdouble_hash(). The latter
two don't exist yet.
The reason is that we want to use siphash24.
Yes, our name differs from glib's. Our naming seems to make sense
to me however, because we also have nm_pstr_hash(), nm_pdirect_hash()
and even nm_ppdirect_hash() for following the pointers. Naming is hard.
- instead of g_int_equal()/g_int64_equal()/g_double_equal() use
our nm_pint_equal()/nm_pint64_equal()/nm_pdouble_equal(). The latter
two don't exist yet. The reason is purely naming consistency since
our hash variants follow the other name.
- move the second g_file_test() inside the if-block. No need to check
twice, if the file exists.
- load_one_nic() can return NULL. Use nm_g_hash_table_lookup() to avoid
NULL pointer assertion.
- use cleanup attribute for "nic" variable, and explicitly pass
ownership on with g_steal_pointer().
The user might still want to see the scan list, to decide whether to
stop the hotspot/ADHOC connection and connect to something else.
Allow explicit scans.
ModuleNotFoundError was only introduced in later python 3 versions.
Use just "ImportError", which is the parent class anyway.
Fixes: f7e484c8ed ('tests: fix "test-client.py" ignoring missing "NM" module')
(cherry picked from commit 9902373c6d)
ModuleNotFoundError was only introduced in later python 3 versions.
Use just "ImportError", which is the parent class anyway.
Fixes: f7e484c8ed ('tests: fix "test-client.py" ignoring missing "NM" module')
If the MAC changes there is the possibility that the DHCP client will
not be able to renew the address because it uses the old MAC as
CHADDR. Depending on the implementation, the DHCP server might use
CHADDR (so, the old address) as the destination MAC for DHCP replies,
and those packets will be lost.
To avoid this problem, restart the DHCP client when the MAC changes.
https://bugzilla.redhat.com/show_bug.cgi?id=2110000
(cherry picked from commit 905adabdba)
If the MAC changes there is the possibility that the DHCP client will
not be able to renew the address because it uses the old MAC as
CHADDR. Depending on the implementation, the DHCP server might use
CHADDR (so, the old address) as the destination MAC for DHCP replies,
and those packets will be lost.
To avoid this problem, restart the DHCP client when the MAC changes.
https://bugzilla.redhat.com/show_bug.cgi?id=2110000
