wpa_supplicant has a property "scanning" and a "state=scanning".
Previously, NetworkManager considered both parts to indicate whether
supplicant is currently scanning (if either the property or the state
indicated scanning, it took that as indication for scanning).
If NetworkManager thinks that supplicant is scanning, it suppresses
explicit "Scan" requests. That alone is not severe, because the "Scan"
request is only to trigger a scan in supplicant (which supplicant
possibly is already doing in state "scanning").
However, what is severe is that NetworkManager will also block autoconnect
while supplicant is scanning. That is because NetworkManager wants to get
a complete scan result before deciding which network to connect to.
It seems that wpa_supplicant can get into "state=scanning" and stay
there indefinitely. This prevents NetworkManager from autoactivating
a profile.
Fix that, to only honor the "scanning" property.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/597
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit 8cadfed2fe)
(cherry picked from commit fbe6240a7d)
During shutdown, NM always tries to remove from ovsdb all bridges,
ports, interfaces that it previously added. Currently NM doesn't run
the main loop during shutdown and so it's not possible to perform
asynchronous operations. In particular, the NMOvsdb singleton is
disposed in a destructor where it's not possible to send out all the
queued deletions.
The result is that NM deletes only one OVS interface, keeping the
others. This needs to be fixed, but requires a rework of the shutdown
procedure that involves many parts of NM.
Even when a better shutdown procedure will be implemented, we should
support an unclean shutdown caused by e.g. a kernel panic or a NM
crash. In these cases, the interfaces added by NM would still linger
in the ovsdb.
Delete all those interface at NM startup. If there are connections
profiles for them, NM will create them again.
https://bugzilla.redhat.com/show_bug.cgi?id=1861296https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/700
(cherry picked from commit e5113a7fd9)
(cherry picked from commit 1125c5d3dd)
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#L490https://bugzilla.redhat.com/show_bug.cgi?id=1900260https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
(cherry picked from commit b0c018830e)
(cherry picked from commit 435d662669)
g_hash_table_iter_next() wants a (gpointer *), not an (int *).
Fixes: f70ee67058 ('dns: sd-resolved: reset interface configuration on deactivation')
(cherry picked from commit 526b484be1)
(cherry picked from commit dedcba61ef)
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 44ebb99cfa)
(cherry picked from commit c182984469)
(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 4fc44952f7)
(cherry picked from commit 3f16b988a4)
(cherry picked from commit cb8737e5a523838fe0bf53008a463d06836e6844)
We will need these changes next:
- add "self" and "ifindex" fields to RequestItem struct. We will
pass on these structs are user-data for the callbacks, so that
we afterwards know which request completed.
- add DBUS_OP_SET_LINK_DEFAULT_ROUTE global variable. We don't
clone the "operation" string but use string literals. However,
string literals are not guaranteed to be deduplicated, so we
should only compare them with strcmp(). The static variable
avoids this: we can use pointer equality to compare it.
This will be used next.
(cherry picked from commit 8af6647cda)
(cherry picked from commit 4401c6d567)
(cherry picked from commit 112d2714c393b56c6ab72e98548652725d458a48)
If the interface is the DNS default route but has no domain, its name
servers were not sent to systemd-resolved. Fix this.
Fixes: ee9fab0361 ('dns: fix handling default routing domains with systemd-resolved')
(cherry picked from commit 195cbf3cee)
(cherry picked from commit ae453f0ae8)
Change the generator to disable by default IP configuration for the
parent connection of a VLAN, because that is what a user would expect
and what the legacy module does. Of course if the user explicitly
configures DHCP or an address for the parent interface, that overrides
the default.
Note that now the generator always creates a connection for the parent
interface. Before this commit, it did only when there was an explicit
ip= argument for the parent interface.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/509
(cherry picked from commit f2e51ace68)
(cherry picked from commit 4b0007b037)
The command line parser looks for a dot or a colon to determine
whether the first token in a ip= argument is a IPv4 address (dot), an
IPv6 address (colon) or an interface name (none). This strategy
doesn't work for interface names containing a dot (typically VLANs).
Instead, try to parse the IPv4/IPv6 address in the token; if this
fails then consider the token as an interface name.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/581
(cherry picked from commit 4aa902ecf5)
(cherry picked from commit f766b3cbae)
This is potentially a breaking change, formerly speciyfing 'none|off'
in the kernel cmdline option 'ip' was understood by the dracut
network-module as doing 'ipv6.method=auto' which is clearly incosistent
with the 'off' naming, thus 'off|none' now means to actually disable
both ipv6 and ipv4 (unless a static ip is provided).
Unit test added.
https://bugzilla.redhat.com/show_bug.cgi?id=1883958
Reverts: 440a0b4078 ('initrd: set ipv6.method=auto when the autoconfiguration field is 'none'')
Signed-off-by: Antonio Cardace <acardace@redhat.com>
(cherry picked from commit fc7c83cbdd)
(cherry picked from commit ad3088f63f)
Fixes: fbf1683c1a ('dns: more debug logging for DNS settings in rebuild_domain_lists()')
(cherry picked from commit 937c8a4669)
(cherry picked from commit b6a9242b1a)
We used to set "~." domains for all devices that should be used for
resolving unknown domains.
Systemd-resolved also supports setting "SetLinkDefaultRoute()".
We should only set the wildcard domain if we want that this
interface is used exclusively. Otherwise, we should only set
DefaultRoute. See ([1], [2], [3], [4]).
Otherwise the bad effect is if other components (wg-quick) want
to set exclusive DNS lookups on their link. That is achieved by
explicitly adding "~." and that is also what resolved's
`/usr/sbin/resolvconf -x` does. If NetworkManager sets "~." for
interfaces that are not important and should not be used exclusively,
then this steals the DNS requests from those external components.
In NetworkManager we know whether a link should get exclusive lookups
based on the "ipv[46].dns-priority" setting.
[1] https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html
[2] https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
[3] https://github.com/systemd/systemd/issues/17529#issuecomment-730522444
[4] https://github.com/systemd/systemd/pull/17678
(cherry picked from commit ee9fab0361)
(cherry picked from commit b8dab47705)
This is nm_assert(). The compiler should be able to completely eliminate
this code in production.
(cherry picked from commit 05f8ccc817)
(cherry picked from commit 0bfc2b6db9)
domain_is_shadowed() only works, because we pre-sort all items. When
we call domain_is_shadowed(), then "priority" must be not smaller than
any priority already in the dictionary.
Let's add an nm_assert() for that.
While at it, I also found it ugly to rely on
GPOINTER_TO_INT(g_hash_table_lookup(ht, domain))
returning zero to know whether the domain is tracked. While more
cumbersome, we should check whether the value is in the hash (and not).
Not whether the value does not translate to zero.
Add domain_ht_get_priority() for that.
(cherry picked from commit 5902f1c91f)
(cherry picked from commit 2502b88511)
There is unnecessary overhead of tracking a separate
key and value in a GHashTable.
Use g_hash_table_add().
(cherry picked from commit d10d96a45c)
(cherry picked from commit 59d48fcc35)
Also, never update the value to %NULL. If the current
message does not contain a UUID, keep the previous one.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
(cherry picked from commit 609b08e2eb)
(cherry picked from commit 0464c36a02)
In connection_removed we use the id.name that was being g_freed a few
lines further down.
Fixes: bea6c40367 ('wifi/iwd: handle forgetting connection profiles')
(cherry picked from commit c1ff06e119)
(cherry picked from commit 03b63a893f)
For hidden networks, we usually don't have an SSID. We try to match
and fill the SSID based on the profiles that we have:
<debug> [1603798852.9918] device[6b383dca267b6878] (wlp2s0): matched hidden AP AA:BB:CC:DD:EE:FF => "SSID"
However, we should not clear that value again on the next update:
<trace> [1603798856.5724] sup-iface[66c1a0883a262394,0,wlp2s0]: BSS /fi/w1/wpa_supplicant1/Interfaces/0/BSSs/3 updated
<debug> [1603798856.5726] device[6b383dca267b6878] (wlp2s0): wifi-ap: updated AA:BB:CC:DD:EE:FF (none)
Once we have a SSID, we can only update it to a better value,
but not clear it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/438
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit eb36380335)
(cherry picked from commit 40edd49025)
Fixes: 395665902b ('dns: don't apply DNS configuration for external connections')
(cherry picked from commit adaeb7a872)
(cherry picked from commit d535da216c)
External connections are devices that are configured outside of
NetworkManager. Such devices should be mostly ignored and not
be interfered with.
Note that we tend to create external connection profiles for
such devices. That happens for example if you use wg-quick to
manage a WireGuard interface outside of NetworkManager. But it
really happens for any interface.
This generated profile has no DNS configuration. Unless we use
the systemd-resolved backend, they thus don't contribute to the DNS
settings (which is fine).
However, with systemd-resolved, NetworkManager would also reset
the DNS configuration of those external interfaces. That is clearly
wrong. NetworkManager should only care about the interfaces that it
actively manages and leave others alone.
How to reproduce: use systemd-resolved and configure an interface outside
of NetworkManager. Note that `nmcli device` shows the state as
"connected (externally)". Note that `resolvectl` shows the DNS configuration
on that external interface. Do something in NetworkManager to trigger
a DNS update (e.g. SIGHUB or reactivate a profile). Note in `resolvectl`
that the external interface's DNS configuration was wiped.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/563#note_673283
(cherry picked from commit 395665902b)
(cherry picked from commit ee4e679bc7)
This results in the args of 'nm_utils_user_data_unpack'
containing random data potentially also from the
previous stack-frame which is really really bad.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Fixes: b50702775f ('device: implement auth-request as async operation nm_manager_device_auth_request()')
(cherry picked from commit b6a18e0593)
(cherry picked from commit 50adaf7414)
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit 3cf8620294)
(cherry picked from commit 4b11029df9)
If a VPN has never-default=no but doesn't get a default route (this
can happen for example when the server pushes routes with
openconnect), and there are no search domains, then the name servers
pushed by the server would be unused. It is preferable in this case to
use the VPN DNS server for all queries.
https://bugzilla.redhat.com/show_bug.cgi?id=1863041
(cherry picked from commit cefd5ee322)
(cherry picked from commit c5b57526ac)
Code doesn't get simpler by having more functions -- if these functions
are only called once.
What actually is a problem is repeated, redundant code. Like the list of
bond options that can be reapplied. But the function didn't help to
avoid repeating the list.
(cherry picked from commit f807b68376)
Add a macro for the list of bond options we are going to set. By seeing
them side-by-side, it is hopefully simpler to see that all options are
specified correctly.
We see that:
- the *_SUBSET defines don't include the options that we are explicitly
setting, that is "mode", "active_slave" and "arp_ip_target".
- OPTIONS_REAPPLY_SUBSET contains 4 options less than OPTIONS_APPLY_SUBSET:
"ad_select", "ad_user_port_key", "lacp_rate" and "tlb_dynamic_lb".
These are the options that are marked as BOND_OPTFLAG_IFDOWN in
kernel.
(cherry picked from commit 5402943420)
I guess the idea was to only accept options that can be changed without
taking the interface !IFF_UP. "active_slave" is wrongly omitted from
that list.
Also, "active_slave" option doesn't really make sense for NetworkManager
to configure. Instead "primary" should be used. In the future, we should
re-map the properties and deprecate "active_slave" for "primary" ([1]).
Fixes: 746dc119a6 ('bond: let 'reapply()' reapply all supported options')
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1856640#c19https://bugzilla.redhat.com/show_bug.cgi?id=1876577
(cherry picked from commit 2eea22ae95)
Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.
Fixes: c056cb9306 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')
(cherry picked from commit bff23d15d4)
