When looking for the dnsmasq (or any) binary, NetworkManager should
check /usr/local before it checks any system installed version. This
allows the user to replace the binary with a newer version should they
desire and is more consistent with the search behaviour commonly found
in $PATH.
https://github.com/NetworkManager/NetworkManager/pull/10
Our internal copy of systemd should not be in the search path.
Instead, let users only
#include "systemd/nm-sd.h"
which then includes everything from systemd that we need.
We want to avoid to accidentally include anything from our
systemd-copy. Any user of that should only include "nm-sd.h",
which then includes everything that is needed further.
For example, "src/devices/wwan/nm-modem-manager.c" has
#include <systemd/nm-daemon.h>
which in turn includes
#include "_sd-common.h"
This works all correctly before, because #include "" will first
look in the directory where sd-daemon.h is. However, our mixing of
external systemd library and internal copy is rather dangerous.
Try to avoid it further by keeping the include paths clean.
Since we possibly already link against libjansson, we can also expose some
helper utils which allows nmcli to do basic validation of JSON without
requiring to duplicate the effort of using libjansson.
Also, tighten up the cecks to ensure that we have a JSON object at hand.
We are really interested in that and not of arrays or literals.
NMPolicy:auto_activate_device() would wrongly not free the
specific_object, although it is documented as transfer-full.
The only implementation of can_auto_connect() that returned
a specific-object is NMDeviceWifi:can_auto_connect(). So, there
wasn't any actual bug or memory leak.
Fixes: 4c028c7cef
First, consider all devices and not only realized and managed ones
when an empty list is passed. Also, move the list evaluation to the
checkpoint manager, since the check for device conflicts is done
there.
Fixes: 3e09aed2a0
In order to better restore the previous system state, allow the
inclusion of unmanaged devices in a checkpoint and try to revert to
the old state taking also the realized/managed state into account.
No need for the setter/getter of this property.
Immutable properties are so much nicer. Remove the setter and
ensure that the nm_plugin_missing property is only set during
object construction.
The data is still unused, the actual fields might change.
Note that the actual state we store is subject to change,
according to which data we need. The file format is non stable,
as the files don't survive reboot. So there is no backward
compatibility to maintain and the format can be changed later.
And drop the unused function nm_manager_check_capability().
I don't think we need such a function server-side, as the
server usually has better ways to check whether a capability
is supported.
dispose() must be re-entrant. Thus, at the very least it must clear the
priv->capabilities after freeing the array.
While at it, move it to finalize (which is only called once) and
move initialization of the array from "constructed" to nm_manager_init()
which is called first.
Unify the two check_ip_done() and check_ip_failed() functions into a
single one to have all the state transition logic in the same place.
This also fixes a regression introduced by commit 553717bb1c
("device: don't set ip4_state=IP_FAIL for ipv4.method=disabled").
After that commit the device immediately proceeded to IP_CHECK when
there was a disabled/ignore method. Now we wait for the termination of
the other method, like it used to be.
Fixes: 553717bb1chttps://bugzilla.gnome.org/show_bug.cgi?id=771579
The 'device-added' and 'device-removed' signals indicate when the
value of the 'Devices' property changes. The property only returns
realized devices and so if a device unrealizes we should emit the
removed signal for it.
Fixes: 5da37a129chttps://bugzilla.gnome.org/show_bug.cgi?id=771324
Some drivers (brcmfmac) don't change the MAC address right away.
NetworkManager works around that by waiting synchronously until
the address changes (commit 1a85103765).
wpa_supplicant on the other hand, only re-reads the MAC address
when changing state from DISABLED to ENABLED, which happens when
the interface comes up.
That is a bug in wpa_supplicant and the driver, but we can work-around by
waiting until the MAC address actually changed before setting the interface
IFF_UP. Also note, that there is still a race in wpa_supplicant which might
miss a change to DISABLED state altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=770504https://bugzilla.redhat.com/show_bug.cgi?id=1374023
This was added by commit 4de8851eca, probably
by copying from NMDeviceVlan. It's not clear why a netlink request to
set the device IFF_UP would fail, or why that warrants a retry.
This retry loop was added by commit dc6341acec.
But I suspect, that the main-point there was not to retry the netlink
request to set the interface up. Why would that fail, and why would
a failure to set the interface up require a retry?
I think it was added to wait for carrier. But waiting for carrier was
later dropped with commit 5074898591
and it is not clear why we would wait for carrier at all -- we don't
do that for other device types either.
Instead of letting the sub-class check the "enabled" state, let
it be handled by nm_device_bring_up().
Note that nm_device_get_enabled() only has two implementations:
NMDeviceModem:bring_up() and NMDeviceWifi:bring_up().
The virtual function NMDevice:set_enabled() has two implementations:
NMDeviceModem and NMDeviceWifi. Likewise, the get_enabled() function
should also be implemented by those types.
The only caller of nm_device_get_enabled() is NMPolicy:schedule_activate_check().
It is correct to skip Wi-Fi devices based on their enabled state.
An empty 802-11-wireless-security.proto is equivalent to
'wpa,rsn'. Previously we added the two protocols when reading the
connection and the variables were missing, with the result that an
empty value would be read as 'wpa,rsn' at the next restart. This is
harmless but makes the two connections appear as different, with bad
effects when 'monitor-connection-files' is enabled.
Ensure that the original value persists after a write/read cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=770907
Long ago before commit 1b49f94, NetworkManager did not touch the
MAC address at all. Since 0.8.2 NetworkManager would modify the
MAC address, and eventually it would reset the permanent MAC address
of the device.
This prevents a user from externally setting the MAC address via tools
like macchanger and rely on NetworkManager not to reset it to the
permanent MAC address. This is considered a security regression in
bgo#708820.
This only changed with commit 9a354cd and 1.4.0. Since then it is possible
to configure "cloned-mac-address=preserve", which instead uses the "initial"
MAC address when the device activates.
That also changed that the "initial" MAC address is the address which was
externally configured on the device as last. In other words, the
"initial" MAC address is picked up from external changes, unless it
was NetworkManager itself who configured the address when activating a
connection.
However, in absence of an explicit configuration the default for
"cloned-mac-address" is still "permanent". Meaning, the user has to
explicitly configure that NetworkManager should not touch the MAC address.
It makes sense to change the upstream default to "preserve". Although this
is a change in behavior since 0.8.2, it seems a better default.
This change has the drastic effect that all the existing connections
out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
I think most users won't notice, because their devices have the permanent
address set by default anyway. I would think that there are few users
who intentionally configured "cloned-mac-address=" to have NetworkManager
restore the permanent address.
https://bugzilla.gnome.org/show_bug.cgi?id=770611
... and don't set ip6_state=IP_FAIL for ipv6.method=ignore.
The disabled state is like having an empty NMIP4Config object.
It should not result in %IP_FAIL state. Instead, we just want
to proceed and commit an empty NMIP4Config instance.
This was introduced by commit 0652d9c596,
which I think was wrong.
Likewise, for ipv6.method=ignore we also don't want to mark the
IP state as failed. Instead, we want to proceed and set IP_DONE
right away -- without commiting anything, which is a difference
to the IPv4 case.
This is especially important, because an ip4_state/ip6_state of IP_FAIL
causes nm_device_can_assume_active_connection() to return FALSE, which
means we unmanage devices at shutdown. Ony might say that it doesn't
matter so much for a device without IP configuration, but imagine a
bond with VLANs on top that only has Layer 2 configuration. This will
bring down the entire stack.
With this change, devices with IP methods disabled/ignore stay up on
exit of NetworkManager (rh#1371126). Of course, that means on restart
software devices stay unamanged due to external-down (because since
commit e1edcda, devices without IP address are also external-down).
So, this really just fixes one scenario, breaking another one.
This should be fixed with bgo#746440 by not assuming connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1371126
