In file included from ./src/libnm-std-aux/nm-default-std.h:102,
from ./src/libnm-glib-aux/nm-default-glib.h:11,
from ./src/libnm-glib-aux/nm-default-glib-i18n-prog.h:13,
from ./src/core/nm-default-daemon.h:11,
from src/core/nm-connectivity.c:8:
src/core/nm-connectivity.c: In function ‘nm_connectivity_check_start’:
./src/libnm-std-aux/nm-std-aux.h:180:12: error: ‘reason’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (expr) \
^
src/core/nm-connectivity.c:1055:29: note: ‘reason’ was declared here
const char *reason;
^~~~~~
The compiler may dislike this:
CC src/core/platform/tests/libNetworkManagerTest_la-test-common.lo
In function '_ip_address_add',
inlined from 'nmtstp_ip4_address_add' at ../src/core/platform/tests/test-common.c:1892:5:
../src/core/platform/tests/test-common.c:1807:63: error: array subscript 'NMIPAddr {aka const struct _NMIPAddr}[0]' is partly outside array bounds of 'in_addr_t[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
1807 | peer_address->addr4,
| ~~~~~~~~~~~~^~~~~~~
../src/core/platform/tests/test-common.c: In function 'nmtstp_ip4_address_add':
../src/core/platform/tests/test-common.c:1886:36: note: object 'peer_address' of size 4
1886 | in_addr_t peer_address,
| ~~~~~~~~~~~~^~~~~~~~~~~~
...
Fixes: 06aafabf14 ('platform/test: add test adding IPv4 addresses that only differ by their peer-address')
The global configuration now can be valid when there are no global
domains defined. The dnsmasq backend must process it and then, if
there is no global default domain, also process the per-connection
settings.
Fixes: 1f0d1d78d2 ('dns-manager: always apply options from [global-dns]')
The link object is no longer valid after the cache gets updated in
nm_platform_link_change().
Fixes: e02fd76d9f ('platform: support changing link properties')
OVS interfaces are special: the kernel link is created only after the
device is attached to the ovs-port, and as with all ports this happens
during stage3(ip-config). That means that the link doesn't exist
during stage2(config); therefore, explicitly update link properties
once the link appears.
We need to set the ethtool and tc properties for assumed devices,
since they go through a normal activation. External devices should not
be touched by NM.
We are passing to the plugin only 'sett_flags', which is the bitmask
of flags to change and works together with 'sett_mask'; however,
plugins interpret that value as the new flags value. The result is
that if there is no change needed (0/0), the existing flags are lost.
Simple reproducer:
ip link add dummy1 type dummy
ip link set dummy1 up
ip addr add dev dummy1 fd01::12/64
sleep 1
# now, a external connection is created by NM
echo "BEFORE:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
# just add a new address to the interface to make it lose
# the external flag
ip addr add dev dummy1 172.25.42.1/24
sleep 1
echo "AFTER:"
cat /run/NetworkManager/system-connections/dummy1.nmconnection | grep "nm-generated\|volatile\|external"
Output:
BEFORE:
nm-generated=true
volatile=true
external=true
AFTER:
Fixes: d35d3c468a ('settings: rework tracking settings connections and settings plugins')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1548
Autoconnect retries are not being tracked by connection anymore. Now it
is tracked per Device x Connection. In addition, autoconnect might be
blocked for the connection due to no secrets or user requested.
All the properties tracking the retries and blocked time were move to
DevConData and the functions to manipulate them aswell. In NMPolicy the
logic didn't change very much. Instead of looking into the connection
when the device failed activation it looks for DevConData.
This setting allows the user to remove the local route rule that is
autogenerated for both IPv4 and IPv6. By default, NetworkManager won't
touch the local route rule.
A tentative IPv6 address can still fail DAD, so don't use it to
resolve the hostname via DNS. Furthermore, tentative addresses can't
be used to contact the nameserver and so the resolution will fail if
there is no other valid IPv6 address. Wait that the address becomes
non-tentative.
Currently the only way to return an error code from the daemon helper
is via the process exit code, but that is not enough to fully describe
an error from getaddrinfo(); in fact, the function returns a EAI_*
error code and when the value is EAI_SYSTEM, the error code is
returned in errno.
At the moment, any messages printed to stderr by the helper goes to NM
stderr; instead, we want to capture it and pass it through the logging
mechanism of NM, so that it can be filtered according to level and
domain.
Improve logging:
- log only when something changes
- print the new resolver state, instead of the old one
- rename state "in-progress" to "started"
- log when the resolver state is reset due to DNS changes
We already get the IAID from the dhclient environment. This is actually
rather useful, because dhclient plugin does not support setting the
value (that is, what we request in "config.v6.iaid" is not actually
used). Already previously, was the IAID for dhclient present in the
lease information. Now also normalize/verify it.
Expose the used IAID also with the internal (systemd) plugin. There we
explicitly set the IAID and know it.
Our lease is tracked in a plain string dictionary. For dhclient plugin
and similar, the keys are received via the environment, they are thus
unlimited. For the internal plugins they are known at compile time and
static strings. We thus sometimes need to clone the string, and
sometimes not.
Unfortunately, we cannot ask the GHashTable whether it has a free
function for the key, so we need to explicitly tell it. Add a parameter
for that.
There should be one function for parsing the string. Use it everywhere.
Also, because we will accept specifying the IAID as hex string so the
same parsing code should be used everywhere.
When a software device is deactivated, normally we schedule a idle
task to unrealize the device (delete_on_deactivate). However, if a new
activation is enqueued on the same device (and that implies that the
new profile is compatible with the device), then the idle task is not
scheduled and the device will normally transition to the different
states (disconnected, prepare, config, etc.).
For ovs-interfaces, we remove the db entry on disconnect and that
makes the link go away; however, we don't clear the hw_addr* fields of
the device struct.
When the new link appears, we try to set the new cloned MAC but the
stale hw_addr field indicates that it's already set. Avoid this
problem by updating the address as soon as the link appears.
https://bugzilla.redhat.com/show_bug.cgi?id=2168477https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1532
- Only consider preferred context of "internet" type. There can be
multiple preferred contexts of multiple types, and we care about
"internet" type only.
- Don't check for "internet+mms" type. It turns out that "internet+mms"
isn't a thing in oFono, and is used to represent "internet" context
with MMSC in the lomiri-system-setting's UI only.
Fixes: 9fc72bf75d ('wwan/ofono: create connections based on available contexts')
Bug-UBports: https://gitlab.com/ubports/development/core/packaging/network-manager/-/issues/3
Trigger a dispatcher event when a connection is reapplied on a NM device.
Some devices such as phones have already a DHCP client running for accepting
connections when they are plugged into USB to transfer data over SSH.
When NetworkManager switches the connection IP method to shared,
it spawns a dnsmasq process to handle DHCP and DNS for that connection.
However, a dispatcher event is needed to disable the external DHCP server
for these USB connections as NetworkManager's dnsmasq handles them now.
Moreover, when the connection method is switched to a different mode,
the external DHCP server needs to be spawned again to make sure that
SSH connections are still possible to the device.
To achieve this, add a new NetworkManager Dispatcher event
'reapply' which is triggered when a connection is reapplied on a NM
device. This way, a dispatcher script can handle the case above by
inspecting the IP method in the dispatcher script.
The onlink flag is part of each next hop.
When NetworkManager configures ECMP routes, we won't support that. All
next hops of an ECMP route must share the same onlink flag. That is fine
and fixed by this commit.
What is not fine, is that we don't track the rtnh_flags flags in
NMPlatformIP4RtNextHop, and consequently our nmp_object_id_cmp() is
wrong.
Fixes: 5b5ce42682 ('nm-netns: track ECMP routes')
If the route with a next hop is already onlink, we don't need to add a
direct route to the gateway.
It also wouldn't work previously, because the onlink route to the
gateway that we would add, would have no gateway and the RTNH_F_ONLINK
set. Kernel would reject that with an error. We would have to clear the
RTNH_F_ONLINK flag, if there is no gateway.
The dns-type must be included in the hash because it contributes to
the generated composite configuration. Without this, when the type of
a configuration changes (e.g. from DEFAULT to BEST), the DNS manager
would determine that there was no change and it wouldn't call
update_dns().
https://bugzilla.redhat.com/show_bug.cgi?id=2161957
Fixes: 8995d44a0b ('core: compare the DNS configurations before updating DNS')
