Let's add a nm_utils_get_reverse_dns_domains_ip() function, which can
operate on both address families. We frequently do that, but then our
address family specific functions tend to have an underscore in the name.
Rename.
I want to add more such accessors, because they are the base for
the corresponding for-each macros.
Add a helper macro _nm_platform_dedup_multi_iter_next() to do that,
which should make it simpler to add these nm_platform_dedup_multi_iter_next*()
functions.
Note that previously these functions were inline functions, now they are
macros. I think there is very little difference here. Also before those
functions could be entirely inlined. By using the macro the result
doesn't really change.
One difference is that we now require an "out" pointer. Previously that
was not required, but I guess it makes little sense otherwise.
We must set these compiler flags independent as to whether this
is a release build or a debug build.
In most cases, we don't differentiate between release and debug build
anyway. Granted, we have "-D more_asserts=100" and set "-O" CFLAGS,
but that is more granular and not a simple "buildtype".
In particular, these compiler flags apply to all kinds of builds.
This is important, because otherwise we get build failures, because
also in release build we want to build with `-Werror` and `-Wall`.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/692
Revert this change. One problem is that none of the current GUIs
(nm-connection-editor, gnome-control-center, plasma-nm) expose the
dns-priority option. So, users tend to have their profile value set to
0. Changing the default means for them not only a change in behavior,
but its hard to fix via the GUI.
Also, what other call DNS leaks, is Split DNS to some. Both uses make
sense, but have conflicting goals. The default cannot accommodate both
at the same time.
Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern
for DNS leaks is smaller. Imagine:
Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com".
VPN profile with ipv4.dns-priority (effectively) 50 and a default route.
That is a common setup that one gets by default (and what probably many
users have today). In such a case with split DNS enabled, the Wi-Fi's DNS
server only sees requests for "*.example.com". So, it does not leak
everything.
Hence, revert this change before 1.28.0 release to the earlier behavior.
This reverts commit af13081bec.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/688
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
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.
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
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
The caller *always* needs to know whether the argument
is an address in binary or text from. At that point,
it's only inconvenient to require the user to either
pass "-1" or ETH_ALEN as size (nothing else was supported
anyway).
Split the function and rename.
Wext is anyway deprected. Our NMWifiUtilsClass should not have API
to accomodate it. That means, we don't need dedicated get_rate(),
get_bssid(), get_qual() hooks, when they all are only called by
get_station().
Instead, push the Wext specific code down.
The macro should require exactly 6 parameters (for the 6 bytes
of the address). On the other hand, we also should be able to
use a macro like
NM_ETHER_ADDR_INIT(NM_BRIDGE_GROUP_ADDRESS_DEF_BIN)
To get that work properly, we need to expand the variadic macro
once.
Also, cast the result to the struct type. With this, it can
not only be used for initialization, but also for assignment
and temporary variables.
These are unused now so remove them and revert most of
e0394689b3 which attempted to fix the same
issue of the platform wifi API not mapping well the nl80211 commands
resulting in redundant netlink commands being used.
In the wext driver there are still three individual getters for the
three values and nm_wifi_utils_get_station() uses either these or the
collective get_station method depending on the driver.
Switch NMDeviceIwd and NMDeviceWifi from nm_platform_wifi_get_bssid,
nm_platform_wifi_get_quality and nm_platform_wifi_get_rate to
nm_platform_wifi_get_station.
I also dropped the checks for the signal quality percentage range as
they're no longer necessary and in NMDeviceWifi dropped
zero-initialization of the bssid buffer before the
nm_platform_wifi_get_bssid call which not necessary either.
Merge nm_platform_wifi_get_bssid, nm_platform_wifi_get_quality,
nm_platform_wifi_get_rate into one utility, nm_platform_wifi_get_station
that uses the single NL80211_CMD_GET_STATION command dump when the
nl80211 driver is used. With wext each function mapped to one ioctl
while with nl80211 all three can be obtained with one netlink command.
The new function should use the minimum number of calls with either
driver.
Watch NMSettingConnection's changes using the
NM_SETTINGS_CONNECTION_UPDATED_INTERNAL signal and update IWD
KnownNetwork's AutoConnect property when NMSettingConnection's
autoconnect property changes.
We will not receive "notify::" NM_SETTING_CONNECTION_AUTOCONNECT signals
normally because the NMConnection seems to be replaced with a new one in
Update2() rather than its settings changing.
Watch the NMDevice::autoconnect property to disable IWD autoconnect if
requested by user. We have no way to re-enable it when the device is
idle though.
Make sure to not disable IWD's autoconnect in .deactivate() if not
necessary. There's not much we can do if we have to call
Station.Disconnect() but we can avoid calling it if unnecessary --
a slight optimization regardless of the autoconnect block flags.
Fortunately NM and IWD block autoconnect on a manual deactivation in
the same way (in MANAGED mode) and unblock it on an activation in the
same way too (in MANAGED mode).
Also if wifi.iwd.autoconnect is in use, unset
NM_DEVICE_AUTOCONNECT_BLOCKED_MANUAL_DISCONNECT under the same
conditions as IWD normally would. This could be made optional but
with wifi.iwd.autoconnect by default we should follow IWD's autoconnect
logic.
If this setting it true (or missing) we skip most of the D-Bus
Disconnect() calls whoe purpose was to keep IWD's internal autoconnect
mechanism always disabled. We use the IWD's Station.State property
updates, and secrets requets through our IWD agent, to find out when IWD
is trying to connect and create "assumed" activations on the NM side to
mirror the IWD state. This is quite complicated due to the many
possible combinations of NMDevice's state and IWD's state. A lot of
them are "impossible" but we try to be careful to consider all the
different possibilities.
NM has a nice API for "assuming connections" but it's designed for
slightly different use cases than what we have here and for now we
created normal "managed"-type activations when assuming an IWD automatic
connection.
Before we call interface_added for all interfaces and objects returned
from g_dbus_object_manager_get_objects(), order the objects based on the
interfaces present on them. This is to avoid processing
Network.KnownNetwork properties referring to KnownNetwork objects that
we haven't processed yet, and new Station.ConnectedNetwork properties
referring to Network objects we haven't processed yet.
In NMDeviceIwd make sure we don't emit unnecessary re-checks if device
is not yet enabled because now we're always going to be adding the APs
(representing IWD Network objects) before the device is enabled, i.e.
before the nm_device_iwd_set_dbus_object() call, when NM first connects
to IWD.
Until now we'd only create mirror NMSettingsConnection objects for IWD
KnownNetwork objects of the "8021x" type in the NMIwdManager class. Now
create mirror connections, or track existing matching
NMSettingsConnections, for every Known Network, for three reasons:
* to allow NMDeviceIwd to easily look up the NMSettingsConnection
matching an externally-triggered connection, specifically when we let
IWD autoconnect,
* to allow users to "forget" those Known Networks,
* to allow us to synchronize the autoconnectable property between
NM and IWD to later allow users toggling it (not done yet).
_nm_utils_ssid_to_utf8() can be quite heavy and also has this comment:
* Again, this function should be used for debugging and display purposes
* _only_.
In most places that we used it, we have already validated the
connection's SSID to be valid UTF-8 so we can simply g_strndup() it now,
even in the two places where we actually only needed it for display
purposes. And we definitely don't need or want the locale-specific
conversions done in _nm_utils_ssid_to_utf8 when the SSID is *not* utf8.
In mirror_8021x_connection we also optimize the lookup loop to avoid
validating and strdup'ing all the SSID.
IWD only supports UTF-8 SSIDs internally, any BSS who's SSID doesn't
validate as UTF-8 is ignored. There's also no way to ask IWD to connect
to such network/start AP/Adhoc etc. because SSIDs are passed as D-Bus
strings. So validate that connection SSIDs are UTF-8 early in
check_connection_compatible/complete_connection and refactor
check_connection slightly to avoid duplication.
Since NMWifiAPs are created by us, we already know those have valid
SSIDs so once we've also checked new NMConnections in
check_connection_compatible there should be no possibility that an SSID
anywhere else in the code is not UTF8. We should be able to treat the
GBytes values as UTF8 without redundant validation or the complex
locale-dependent conversions in _nm_utils_ssid_to_utf8.
The AP BSSIDs created by the iwd backend are made up so never lock the
connections to them. It probably wouldn't matter as long as the iwd
backend is used but the fake BSSID could stay in the connection
properties even if the user switches to wpa_supplicant.
set_current_ap() would always call schedule_periodic_scan() but: first it
would do nothing when current_ap was non-NULL because we
schedule_periodic_scan makes sure not to auto-scan when connected.
Secondly state_changed() already calls schedule_periodic_scan
indirectly through set_can_scan() so normally when we disconnect and
current_ap becomes NULL we already do trigger a scan. The only
situation where we didn't is when a connection is cancelled during
NEED_AUTH because IWD's state doesn't change, so we add a
schedule_periodic_scan() call in network_connect_cb() on error.
Rename NMDeviceIwdPrivate.can_connect to .nm_autoconnect in preparation
to also add .iwd_autoconnect.
Rename misnamed local variable iwd_connection to nm_connection, we'll
need a new iwd_connection variable later.
In this state, same as in DISCONNECTED or ACTIVATED, allow scanning if
IWD is in the "connected" or "disconnected" states as there's no reason
not to scan.
Implement a Cancel method on our IWD secrets agent DBus object. This
results in a call to nm_device_iwd_agent_query() for the device
currently handling the request and the @invocation parameter is NULL to
signal that the current query is being cancelled.
nm_device_iwd_agent_query doesn't do much with this call just yet but
the handling will be necessary when IWD autoconnect is used by NM.
