Fixes: 32f4abe90b72 ('config: warn about unknown keys in config files')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/595
(cherry picked from commit d615b902d8ded3f5de36704a3f3f00680899b40b)
(cherry picked from commit 3b1ae89d2fa5b612a9a87a8949100aa264c40a86)
The parser checks if the first token of an ip= argument is an IP
address to determine which of the two possible syntaxes is used:
ip=<interface>:{dhcp|on|any|dhcp6|auto6}[:[<mtu>][:<macaddr>]]
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<mtu>][:<macaddr>]]
This works as long as the first token is not empty, which - according
to the dracut.cmdline man page - seems to be guaranteed.
However, the network-legacy dracut plugin accepts an empty interface
or client IP. Also, if a user needs DHCP and wants to specify a
hostname, the only possible syntax is:
ip=::::<hostname>::dhcp
Change the parser to check the second token instead, similarly to what
the network-legacy module does [1].
[1] https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/net-lib.sh#L490
https://bugzilla.redhat.com/show_bug.cgi?id=1900260
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
(cherry picked from commit b0c018830e7884e7457b8ea44553946ff680eb89)
(cherry picked from commit 435d662669cf487abe91c31b94ac71239073ce98)
g_hash_table_iter_next() wants a (gpointer *), not an (int *).
Fixes: f70ee67058c9 ('dns: sd-resolved: reset interface configuration on deactivation')
(cherry picked from commit 526b484be1981b4bfcc5e48d5480c6ac7ccd8b66)
(cherry picked from commit dedcba61ef79c09c40eeaea3aa90a871097cbda3)
Dunno why this file now gets generated. (cherry picked from commit df76da8ea0d6994b5611c64ca66f7f86d233b541) (cherry picked from commit 76ba56c7bf17e2da5cf32c59c55e83bdc3eb774c)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/694 (cherry picked from commit bb9dcde97f9667fa39222b26ec86e6cde2aa94f2) (cherry picked from commit e749a1a5dbce2f858d32b68f742f2cd336863fe2)
We now always use SetLinkDefaultRoute(), but that API was only added in systemd v240 ([1]). We could just always call the non-existing method, and ignore the error. However, that feels ugly. Would systemd-resolved log warnings about that? Should we suppress all messages about that failure (not good for debugging). Instead, make an effort to detect support of the function, and avoid calling it. That is significantly more complicated than just always calling the method and not care. Note that even if systemd-resolved does not support SetLinkDefaultRoute(), we cannot do anything smart about that. We would simply rely on systemd-resolved (hopefully) doing the right thing automatically. That's better and simpler than explicitly adding a "~." domain in the fallback case. Also, detecting support is straight forward in the common case, where there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod" error. In cases where there is any other failure, we don't really know. In that case, we keep trying to use the API under the assumption that it should work. [1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4 (cherry picked from commit 44ebb99cfaf4c5db350f090b133b5048e188b9d5) (cherry picked from commit c182984469389ece405180874040de3c21ee269c) (cherry picked from commit c469283893c82a10a31d3162e0e7e41258cd9ec8)
When the DNS settings change, we update the request_queue_lst_head list, with all the requests we want to send. Then, send_updates() will try to send it. It might not do it right away, if resolved is not on the bus or the D-Bus connection is not fully inialized (meaning, we don't know the name owner yet). In those cases, we would keep the list of requests, and send them later. However, when sending them, we would also forget about the configuration. That means, if you restart systemd-resolved, then the daemon drops off the bus and reappears. I think that systemd-resolved in fact persists the configuration during restart. So, usually the settings are still the same after restart. However, we should do better here: if the service appears, we should send the settings again. This means to not forget the requests after we send them once -- at least, until a new update replaces them. (cherry picked from commit 4fc44952f7fd44771a1c006529cea6db937290ec) (cherry picked from commit 3f16b988a49a731eb0fd94d2f96b0fc505cd62da) (cherry picked from commit cb8737e5a523838fe0bf53008a463d06836e6844)