When the operation is cancelled, we must not touch user_data. Note that
NM_POLICY_GET_PRIVATE() theoretically doesn't dereference the pointer
(does it?) but doing pointer arithmetic on a dangling pointer is a very
ugly thing to do.
And of course, the memleak.
Fixes: 5c716c8af8
Fixes: a2cdf63204
(cherry picked from commit 3215508293)
(cherry picked from commit f1469558c0)
NMDeviceGeneric:check_connection_compatible() doesn't check for a
matching interface name. It relies on the parent implementation to
do that.
The parent implementation calls nm_manager_get_connection_iface().
That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has
no factory. Maybe this imbalance of having no factory for the Generic device
is wrong, but usually factories only match a distinct set of device
types, while the generic factory would handle them all (as last resort).
Without this, activating a generic connection might activate the
wrong interface.
(cherry picked from commit 3876b10a47)
(cherry picked from commit 753a2cc4d9)
(cherry picked from commit bd72919b47)
VLANs already inherit the MTU from parent device when manually
activated. At boot, since the vlan interface is created before
activating the parent, the MTU is left to the default value.
Fix this by inheriting the MTU from parent when activating the
VLAN. Note that this change is effective only when the connection has
an actual IPv4 configuration; for all other cases users should
explicitly set the desired MTU value in the 'ethernet.mtu' property.
See master commit 7dde8d8106 ("vlan: use parent interface mtu as default")
https://bugzilla.redhat.com/show_bug.cgi?id=1439166
It also used __bitwise and __force. It seems easier to rename
our versions since they are local to this one single header.
Also, undefine them afteerwards, so that we don't pollute the
preprocessor macro namespace.
https://github.com/systemd/systemd/pull/5061
(cherry picked from commit 13b2ac2214)
Also accept DEFROUTE and GATEWAY when they are defined in
alias files -- provided, that they are not yet defined
in the main ifcfg file.
(cherry picked from commit 3cc00dd550)
(cherry picked from commit 4c595997f2)
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
(cherry picked from commit a8f0d88596)
(cherry picked from commit be1daa4580)
The default route manager logs for each entry relevant information,
in a compact but cryptic way:
default-route: entry[0/dev:0x5633d5528560:enp0s25:1:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
The flag whether a route is configured or not, was only expressed
via 0|1. Change that to log instead:
default-route: entry[0/dev:0x5633d5528560:enp0s25:+has:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
(cherry picked from commit 82bfb6c46d)
Whenever we call update for a non-assumed, synced route, we must
force a resync with the platform. Even if according to our internal
book-keeping the route is already configured, the route may have
been removed externally. So we cannot assume that everything is
still up-to-date.
https://bugzilla.redhat.com/show_bug.cgi?id=1431268
(cherry picked from commit c3c251ea12)
Avoid using new_settings when they are none. Also, don't shortcut when
the connection hasn't been changed -- let the settings plugin decide if
it needs to rewrite the connection.
(cherry picked from commit b47340fd3f)
(cherry picked from commit 58c9a41959)
GLib 2.52 added a G_GNUC_PRINTF attribute to
g_dbus_message_new_method_error(). This triggered warning in
NetworkManager when built with -Wformat, which is an error when built
with -Werror=format-security. It seems that gcc isn't smart enough to
see that (foo = "bar") should be treated as a literal.
Fortunately there is a g_dbus_message_new_method_error_literal()
function which does not take printf-style arguments, and we don't need
them, so we can use that.
This patch was originally by Rico Tzschichholz <ricotz@ubuntu.com>, and
was submitted to Launchpad at
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1650972https://bugzilla.gnome.org/show_bug.cgi?id=780444
(cherry picked from commit 6a77258f4e)
(cherry picked from commit 1715ec53c1)
NM always asks pppd to run IPV6CP which will complete if the modem supports
IPv6. If the user doesn't want IPv6 then NM just ignores the result. But
if the host has disabled IPv6, then pppd will fail to complete the connection
because pppd tries to assign the Link-Local address to the pppX interface,
and if IPv6 is disabled that fails and terminates the PPP session.
So only request IPV6CP when the user wants IPv6 on the connection; if they
have disabled IPv6 on their host then they can simply set ipv6.method=ignore.
https://mail.gnome.org/archives/networkmanager-list/2017-March/msg00047.html
(cherry picked from commit 8d4570d28d)
When remove_device() is called on an already unrealized device, we
should release it from master if necessary and clear its IP
configurations to avoid leaks.
https://bugzilla.redhat.com/show_bug.cgi?id=1433303
(cherry picked from commit 2e0c3d1dac)
(cherry picked from commit 427a3e5cff)
Instead of throwing an assertion, fail DHCPv6 when a IPv6 link-local
address is not configured on the device. There are different reasons
why the assertion may fail: for example the address was removed
externally; or the device is gone (and thus the platform already
received the notification of addresses removal) but the device is still
connecting because its disposal happens in an idle callback.
None of these deserves an assertion, which should only be for
programming errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1432251
(cherry picked from commit 4987ec408a)
(cherry picked from commit 238fc87298)
This makes it more likely that the user will end up with a master
connection that has connection.interface-name property. This makes it
possible for ifcfg plugin to specify the master in the for of device
name (as opposed to UUID) for compatibility with the legacy network
tooling.
This is equivalent to what nmcli does.
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
(cherry picked from commit ff46158d9e)
ip4_addr_subnets_is_secondary() should fill the list of addresses in
the same subnet also when returning FALSE, because
nm_platform_ip4_address_sync() uses it.
Fixes: 2f68a50041
(cherry picked from commit a347962831)
nm_platform_ip4_address_sync() tries to apply the new configuration
with the minimum effort and doesn't delete addresses if they are
already present on the interface. This can break the ordering, as an
existing address would be promoted by kernel to primary, even if it
was last in our configuration.
Add some logic to ensure the correct order of addresses is always
enforced. This fixes situations like:
# nmcli connection add type ethernet ifname eth0 con-name t \
ipv4.method manual \
ipv4.addresses "1.1.1.1/24,1.1.1.2/24,1.1.1.5/24"
# nmcli connection up t
=> addresses are applied in the right order:
inet 1.1.1.1/24 brd 1.1.1.255 scope global eth0
inet 1.1.1.2/24 brd 1.1.1.255 scope global secondary eth0
inet 1.1.1.5/24 brd 1.1.1.255 scope global secondary eth0
# nmcli connection mod t ipv4.addresses "1.1.1.5/24,1.1.1.2/24,1.1.1.1/24"
# nmcli device reapply eth0
=> order is wrong:
inet 1.1.1.2/24 brd 1.1.1.255 scope global eth0
inet 1.1.1.5/24 brd 1.1.1.255 scope global secondary eth0
inet 1.1.1.1/24 brd 1.1.1.255 scope global secondary eth0
Co-Authored-By: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 2f68a50041)
We no longer use wpa_supplicant for MAC address randomization. Instead, NetworkManager
handles it on it's own. It is actually important that supplicant does not interfere
when setting the MAC address of the device.
The code was only in effect when supplicant has a PreassocMacAddr property.
As this is a recent feature, the left-over code wasn't noticed until now.
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00003.html
Fixes: 767abfa690
(cherry picked from commit 0cb85f161e)
(cherry picked from commit 7ada0e0bc3)
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
(cherry picked from commit 27cba47957)
(cherry picked from commit 491ccd9d64)
At some point gobject-introspection added an API to add a library path
and stopped honoring the LD_LIBRARY_PATH (a bug, according to GI
documentation?).
(cherry picked from commit 6c96aafaa9)
(cherry picked from commit 2ee8462774)
At least with my supplicant, the capability is called
all-upper-case "FAST".
The check used case-insensitive, but that was broken
by a previous change.
Fixes: 9f5f141100
(cherry picked from commit 66ff601ecf)
(cherry picked from commit 1caae3743d)
We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the
network.service did, confusing the legacy tooling. Let's do our best to write
compatible configuration files:
* Add *_UUID properties that won't clash with initscripts
* Ignore non-*_UUID keys on read if *_UUID is present
* If the connection.master is an UUID of a connection with a
connection.interface-name, write the uuid into the *_UUID key while setting
the non-*_UUID key to the interface name for compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
(cherry picked from commit 8b7b0d3fc2)
Move the updating/setting of the ip-ifindex/ip-iface to one place.
Properties should be for the most part immutable/read-only, and only
at particular places modified. That way, it's easier to track who
changes a property.
Also, add a logging line with "ip-ifname" prefix.
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00011.html
(cherry picked from commit 78017f1bdc)
The kernel already takes care of adding and updating temporary
addresses when an address with IFA_F_MANAGETEMPADDR flag is added or
updated; doing it also in nm_platform_ip6_address_sync() can overwrite
the changes done by kernel, especially because since commit
0a0bca9c7f ("ip6-config: sort addresses only when reading the
property value") there is no guarantee that temporary addresses are
before the public ones in the IPv6 configuration.
Still delete temporary addresses, but don't add or update them.
(cherry picked from commit 1dbd9d7948)
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
(cherry picked from commit a9384452ed)
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
mac-address-randomization as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
(cherry picked from commit 46d53e1101)
We set a dedicated route to reach the VPN gateway only if the parent
device has a gateway. If the parent device doesn't have a gateway (for
example in case of GSM connections) and the VPN gets the default
route, the VPN gateway will be contacted through the VPN itself, which
obviously doesn't work.
Set up a device route if the parent device doesn't provide a gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1403660
(cherry picked from commit ae5adc9e21)
