For delete-events, we only need a shallow object with the key fields
set. That sufficies to lookup in the cache and find the object to
delete.
One other issue is that _nmp_vt_cmd_plobj_init_from_nl_link() and
link_extract_type() might call to ethtool for the already deleted
instance. Just avoid that.
https://bugzilla.redhat.com/show_bug.cgi?id=1247156
(cherry picked from commit a4c7176fe9)
Add an assert (g_return_val_if_reached()) that the interface name is
valid and shorter then 16 bytes. If it happened to be longer, strncpy()
would not have zero terminated the interface name.
(cherry picked from commit 5b123f2539)
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
In C function() and function(void) are two different prototypes (as opposed to
C++).
function() accepts an arbitrary number of arguments
function(void) accepts zero arguments
(cherry picked from commit 94a393e9ed)
Move the check for a platform link before devtimeout_from_file(). The
check in the platform cache should be more performant and yield success
in most cases.
This can save reading and parsing the ifcfg-rh file.
(cherry picked from commit 6608331aec)
If NIC related initialization takes a long time in udev processing, but we have
an ifindex from kernel, we still want to wait until udev is finished and the
device is really usable.
Check that by calling nm_platform_link_get_by_ifname() and checking @initialized,
which means udev is finished.
Based on a patch by t-nishimura@hf.jp.nec.com
Improved by thaller@redhat.comhttps://bugzilla.redhat.com/show_bug.cgi?id=1192633
(cherry picked from commit ecdf7cba6b)
If linklocal6_start() finds that the device already has an IPv6
link-local address and returns NM_ACT_STAGE_RETURN_FINISH, we don't
need to fill @out_config with an empty configuration. A non-NULL
@out_config is required only for ret = NM_ACT_STAGE_RETURN_SUCCESS.
Fixes: 396dc2b3b4
(cherry picked from commit 54d10f0ec1)
Seems that team changed to now also raise two change signals.
Relax the assertion that broke tests on Fedora 22.
(cherry picked from commit 1c2883c940)
During merge_and_apply(), we merge several NMIPxConfig into a new
@composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to
prevent certain routes/dns-settings to be merged.
But it is wrong to reject settings from all partial configs.
For example, especially ext_ipx_config and vpn_ipx_config contain
routes that we still must merge and preserve.
This was recently changed by 79630c11e5
and previously by ab6548c621. But it was
wrong for a long time already.
Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and
dns-options.
https://bugzilla.gnome.org/show_bug.cgi?id=752546
Fixes: 79630c11e5
(cherry picked from commit 43e6f6a178)
The new flags are not yet used, so there is no change in functionality.
The flags NM_IP_CONFIG_MERGE_NO_ROUTES and NM_IP_CONFIG_MERGE_NO_DNS go
together with the 'ignore-auto-routes' and 'ignore-auto-dns' setting.
Note that for IPv4, NM_IP_CONFIG_MERGE_NO_DNS also ignores NIS, WINS, and dns-options.
This is different from current other places that handle 'ignore-auto-dns'
and only care about nameservers, domains, and searches.
(cherry picked from commit f7a8962dd4)
The MTU of 0 means default, not zero-length packets:
<warn> (wlp3s0): Lowering IPv6 MTU (1472) to match device MTU (0)
<warn> (wlp3s0): IPv6 MTU (0) smaller than 1280, adjusting
<warn> (wlp3s0): Raising device MTU (0) to match IPv6 MTU (1280)
<error> [1437068831.306733] [platform/nm-linux-platform.c:2440] sysctl_set(): platform-linux: sysctl: failed to set '/proc/sys/net/ipv6/conf/wlp3s0/mtu' to '1472': (22) Invalid argument
Reported-by: Jan Alexander Steffens <jan.steffens@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752508
(cherry picked from commit a92d8b0c67)
Try to set the MTU of the parent Ethernet interface to match the
requested PPP MTU and MRU. This allows the negotiation of a PPP MTU
and MRU greater than 1492.
(cherry picked from commit 1d3eff45d2)
Fix wrongly managing the default-route on unmanaged devices. Also,
improve handling for p2p link with an 0.0.0.0 IPv4 gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1244483
(cherry picked from commit 7243c9f3d4d0c0d0508c9bed326eea99336196bd)
Remove an assertion in canonicalize_ip() to assert that either a
non-NULL @ip is given, or @null_any is TRUE.
The condition of the assert is not easy to understand without context.
Instead the caller should already handle %NULL properly.
All callers that pass @null_any=FALSE to canonicalize_ip(), already assert
that the argument is not %NULL. With the exception of nm_ip_route_new()
which however checks for a valid @dest early on.
(cherry picked from commit 7f129b976c)
We call valid_ip() from nm_ip_route_new() to check whether an untrusted string
is a valid ip address. Properly handle %NULL argument.
Fixes: 21c8a6b20e
(cherry picked from commit 9342568694)
A is_valid() function should just accept NULL as input and
return "invalid". It certainly should not crash.
Fixes: 21c8a6b20e
(cherry picked from commit 2b55de8560)
Commit d51975e changed, that we treat assumed and non-assumed
connections the same with respect to the default route. This is
certainly wrong, if we have an nm-generated-assumed connection
at hand. In this case, NM just generated a connection based on what
was configured on the system. Looking at that result and re-enforcing
the default-route is wrong.
We want to manage the default-route for assumed, persistent connections.
If the connection was assumed and generated, we do not.
This commit reverts d51975ed for nm-generated-assumed connection and
restores the previous behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1244483
Fixes: d51975ed92
(cherry picked from commit bebeff69e8)
Rename "default_route.v4_configure_first_time" to "v4_commit_first_time".
For one, the name "commit" matches better to the @commit variable in ip4_config_merge_and_apply()
and ip6_config_merge_and_apply(). Then, we don't need this information
only for default-routes, so move the variable out of the @default_route
struct.
(cherry picked from commit ad03cdbc73)
When generating a connection to assume it, also record the route-metric.
Do that by looking at the metric of the (best) default-route.
This is especially important since d51975ed92.
Now NM would also manage the default-route for assumed connections.
So the generated assumed connection would have a route metric based on
the device type, which might differ from the external configuration.
This caused NM to replace the externally configured default-route.
https://bugzilla.gnome.org/show_bug.cgi?id=750405
(cherry picked from commit bc75cd53a8)
nmc_property_connection_get_metered() must return non-localized strings
that can be parsed by nmc_property_connection_set_metered().
Fixes: f0aebfd746
(cherry picked from commit 5eba53cd53)
This introduces a global metered property which makes easier for
clients to obtain the metered status of the current primary
connection.
(cherry picked from commit 04d5804dd5)
Valid values must not be translated in error messages generated in
nmc_string_to_bool() and nmc_string_to_tristate().
(cherry picked from commit bd4e1f37f8)
Change type of return value and 'def' argument of svTrueValue() to
gint to make clear that it can be something different from TRUE and
FALSE.
(cherry picked from commit 862fd91df0)
The metered property of a NMDevice that reaches the activated state is
copied from the active connection and if its value is 'unknown' some
heuristics are used to guess the actual value.
When the connection is torn down the metered property is reset to
'unknown'.
(cherry picked from commit a86255a043)
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)
