Some versions of Android's DHCP server send option 43 (Vendor specific
information) with value "ANDROID_METERED" in Wi-Fi hotspot mode.
Mark the NMIP4Config as metered when such option is received.
(cherry picked from commit 1e39b2320d)
This adds support for DHCP option 43 (Vendor Specific Information) to
the internal DHCP client. The option carries an opaque object of n
octets, interpreted by vendor-specific code on the clients and
servers.
(cherry picked from commit 3c2f4a17f9)
Some DHCP servers send specific options to give a hint that clients
should avoid unneeded data usage.
Add a metered flag to NMIP4Config to keep track of this information.
(cherry picked from commit 68db65b727)
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
(cherry picked from commit 6f647fe689)
This makes wifi preferred to wwan (the modem and bluetooth device types
to be specific) by default, so that users that care about being
connected at all times can keep both enabled with auto-connect. As wifi
is usually unmetered and often faster than wwan, it makes sense to
prefer it. This is also how pretty much every smart-phone in the world
behaves, so it aligns better with user expectations too.
https://bugzilla.gnome.org/show_bug.cgi?id=744754
(cherry picked from commit 3efb6740fc)
Some of the properties changed from GParamSpecUInt to GParamSpecFlags, namely
NM_SETTING_VLAN_FLAGS
NM_SETTING_DCB_APP_FCOE_FLAGS
NM_SETTING_DCB_APP_ISCSI_FLAGS
NM_SETTING_DCB_APP_FIP_FLAGS
NM_SETTING_DCB_PRIORITY_FLOW_CONTROL_FLAGS
NM_SETTING_DCB_PRIORITY_GROUP_FLAGS
(commit fcfb4b40ba)
https://bugzilla.redhat.com/show_bug.cgi?id=1244048
(cherry picked from commit 94b1b53a91)
If the VPN plugin terminated and the user started it again, then the
quit timer will still be running and it sometimes happens that the
VPN plugin will quit while the UI is asking the user for secrets.
That's not very nice, so don't do that.
Reproducer: while connect to the VPN, suspend your laptop. Then
resume it, and immediately re-start the VPN connection. Watch the
secrets dialog disappear within a very short time.
https://bugzilla.gnome.org/show_bug.cgi?id=752237
g_convert_with_fallback() will fail if the SSID contains characters that
are not legal in the source encoding, which, if $LANG is not set, will
be ASCII. If this happens, replace all non-ASCII and non-printable
characters with '?'. It is possible that nm_utils_ssid_to_utf8() will
now return an empty string (e.g., the source string is actually
big-endian UTF-16 and g_strcanon() stops on the first byte), but it will
not return NULL.
https://bugzilla.redhat.com/show_bug.cgi?id=1243078
(cherry picked from commit 568b4ad31f)
Fix route manager not to delete externally added routes
but only routes that were previously added by route manager.
Also, add a test case and refactor the _exists() functions
to have them more useful.
(cherry picked from commit 5cc2eabe5d)
In most cases, when syncing routes, we should only remove routes
that were configured by us previously. Otherwise, there is a race
that we can remove routes added externally.
Now, when applying IP configuration for a device, only do a full-sync
at the first time when we activate the device. Later on, only remove
routes that were added by us.
(cherry picked from commit 8b015826e6)
Add an argument @full_sync to the sync method of NMRouteManager.
@full_sync was what we did up to now, meaning, we removed every
route on the interface that was no on our internal list of known
routes.
Now with !@full_sync, only remove routes that were tracked previously.
This means, we will only remove routes that were added by us previously.
Don't make use of the new option yet. So there is no change of behavior
yet.
(cherry picked from commit 65f2090cc2)
This is done to silence coverity. In the dispatcher the existence of the
key is checked before and we're fine with leaving the value untouched
in the vpn-plugin-old.
(cherry picked from commit a9996c4f1d)
Coverity detected that it was always-true:
src/platform/nm-linux-platform.c:4035: dead_error_line: Execution cannot reach the expression "preferred != 0U" inside this statement: "if (lifetime != 0U || lifet...".
(cherry picked from commit da612acc6a)
It is wrong to only consider internal_gateway of the VPN connection.
Instead, we must first set the gateway of NMIP4Config and then overwrite
it with the connection settings.
(cherry picked from commit 691ebbdc43)
For non-tunnel based VPNs (openswan, libreswan), we must
clear the gateway setting. The default route is managed
by NMDefaultRouteManager, and we must not overwrite the
gateway of the parent device.
This fixes a bug if the VPN connection specifies a gateway, it
would have overwritten the gateway of the underlying device.
(cherry picked from commit 1465c1d326)
The gateway property of NMIP4Config/IP6Config determines the next hop
for the default route. That is different from the @external_gw property
of the VPN which is the address of the world-reachable VPN gateway.
It is wrong to set the gateway of the VPN's IP config to the external gateway.
This causes ip4_config_merge_and_apply() to overwrite the gateway of the
underlying device.
Instead, NMDefaultRouteManger gets the gateway directly from the VPN
connection by quering nm_vpn_connection_get_ip4_internal_gateway().
(cherry picked from commit 5cd1316100)
When a VPN has no default route, it is wrong to enforce the absence
of a default route on that device. Instead, if there is no default
route, NMDefaultRouteManager should just forget about the route.
This is especially important, because for VPN types like openswan
there is no distinct tunnel interface. Instead, it shares the ifindex
with the parent-device.
Note that devices usually only enforce their default-route for a short
time and afterwards switch to non-synced. If that happens and there
is a VPN that enforces the absense of the default route on that device,
we end up deleting the default route.
(cherry picked from commit 16d0850c37)
We currently don't manage a veth inside a container despite we should because
it's an externally configured software interface and thus waits for IFF_UP.
Given veths are prevented from being managed outside of a container by an udev
rule anyway it's safe to lift the external IFF_UP requirement for them.
(cherry picked from commit bcc79cc0eb)
