| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
It's not needed. Whenever we add a route, we pass in the
route metric (for example, based on the device's configuration).
No need to merge and track it into the NMIP4Config/NMIP6Config.
The metric was only used in nm_ip4_config_create_setting()
and nm_ip6_config_create_setting(). In fact it's wrong to do
that, because it means we first capture some settings, and guess
the configured route metric. But we cannot do that. Our best
guess what a configured setting might be is -1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSS is only set for VPN connections (by merging it in the respective
NMIP4Config/NMIP6Config).
It is also only used when setting the MSS of the default route.
Don't track that property in NMIP4Config/NMIP6Config, instead, set the
mss of the route directly in nm_vpn_connection_ip4_config_get() and
nm_vpn_connection_ip6_config_get().
There is a potential change in behavior here: NMDevice also consisdered
the MSS for the default route, but that would only be set if the MSS
gets merged from an vpn-ip-config. Which at most is the case for
iterface-less VPN types (libreswan). But even in that case, it doesn't
seem right to me to use the VPN's MSS for the device's default-route.
|
|
|
|
| |
Including device-routes, default-route, SLAAC.
|
|
|
|
| |
Including device-routes, default-route, DHCPv4, IPv4LL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
|
|
|
|
|
|
| |
How nice would it be to have a NMIPConfig class that is
agnostic for IPv4 and IPv6. Another small step, in unifying
v4 and v6.
|
| |
|
|
|
|
|
|
|
|
|
| |
- merge the IPv4 and IPv6 implementations. They are for the most
part identical. Also, they are independent of NMIP4Config/NMIP6Config.
- parse the entire file at once. Don't parse it twice, once for the
name servers and once for the options. This also avoids loading
/etc/resolv.conf twice, as it would be done before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
These static variables really never be modified.
Mark them as const, which allows the linker to mark them as
read-only.
The problem is libnl3's API, which has these parameters
not as const. Add a workaround for that. Clearly libnl3 is
not gonna modify the policy, that the API was fixed too [1]
[1] https://github.com/thom311/libnl/commit/b4802a17a7655bfeee3e9c06e649d30b96dbad3b
|
| |
|
|
|
|
|
|
| |
Due to a typo the flag was set on ipv4
Fixes: ddfeed4530bb0ade4249025930da4f0456026d9f
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1371289
|
|
|
|
|
|
|
|
|
|
|
|
| |
The line
device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed)
prints the sys-iface-state, which is at other places logged with
device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed
For consistency, name the same parameter the same.
|
|\
| |
| |
| |
| |
| |
| | |
Merge an early part of the branch, with independent cleanups
and refactoring.
https://bugzilla.redhat.com/show_bug.cgi?id=1436531
|
| |
| |
| |
| |
| |
| |
| |
| | |
The name "priority" is well established for routes (e.g. kernel's
RTA_PRIORITY netlink attribute).
However, we call it at most places "metric" or "route_metric".
Rename it, not to use two different names for the same thing.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The name nm_device_get_priority() is misleading. Nowadays it's only used
for the default route metric, and nothing else.
Rename it, and make it static.
|
| |
| |
| |
| |
| |
| | |
nm_device_get_route_metric()
Brevity!
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_utils_parse_inaddr_bin()
One might already question the existance of nm_utils_parse_inaddr_bin(),
because it only wraps inet_pton(), which by itself isn't terrible API.
The reason nm_utils_parse_inaddr_bin() exists, is to mirror to nm_utils_parse_inaddr()
function, which has additional functionality on top of inet_pton().
But we shouldn't have more then one wrapper for inet_pton().
|
| |
| |
| |
| |
| |
| |
| |
| | |
on success
The documentation of inet_pton() is not clear about what happens
when parsing fails. Guarantee that the output is only modified
on success.
|
| |
| |
| |
| |
| |
| |
| | |
The addr_family should be the first argument. It mirrors inet_pton()
and is just nicer.
Also, rename the argument from "family" to "addr_family".
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For some logging lines this changes the domain
from LOGD_PPP or LOGD_MB|LOGD_IP4 to LOGD_MB.
Also, it changes the format of the prefix, and
adds a prefix for some logging lines that didn't
have one previously.
|
|/
|
|
|
|
|
|
|
| |
We already have nm_strquote_a(). That is useful, but uses alloca(), hence it
is ill suited to be called from a macro, inside a loop, or from a function
that should be inlined.
Instead, add nm_strquote() that has the same purpose but writes to a provided
string buffer.
|
|
|
|
|
|
|
|
|
| |
gcc doesn't consider variables with cleanup attribute as unused.
clang does, and warns about them.
In one case, clang is right, in the other one the warning is bogus.
Fix both.
|
|
|
|
|
|
|
|
|
|
| |
Found by clang warning:
src/devices/nm-device.c:11370:14: error: use of logical '||' with constant operand [-Werror,-Wconstant-logical-operand]
|| NM_UNMANAGED_USER_UDEV
^ ~~~~~~~~~~~~~~~~~~~~~~
Fixes: 5778bc6a34f2291d68247695119f2170bc3bf8b3
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1454883
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
No flags yet implemented.
https://bugzilla.redhat.com/show_bug.cgi?id=1454883
|
| |
| |
| |
| | |
Introduce a set-function, will be used later.
|
| |
| |
| |
| |
| |
| |
| |
| | |
nm_utils_to_string_buffer_init()
These are just simple utility functions, not tied to NetworkManager
core. Move them to shared/nm-utils, so that they may be reused
otherwise.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allow passing a pretty name for the zero flag 0, like "none".
Also, don't require flags to be power-of-two. Instead, allow names for
multiple flags. For example an "all" name. By specifying multi-value
flags first, their nick will be supersede the more specific flags.
Probably it doesn't make sense in usual cases, but nm_utils_flags2str()
should prevent such use.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
If unrealize() failed we returned without thawing notify signals. Fix
this by moving g_object_freeze_notify() after the
unrealization/deletion but before the properties are reset in
unrealize_notify().
Fixes: a93807c288743f499362f7edfe0674020762811c
|
|
|
|
| |
Fixes: cfb14ce17e77916d8998d444a05cdea726723240
|
|
|
|
|
|
|
|
| |
- clearify in the manual page that setting retry to 1 means to try
once, without retry.
- log the initially set retry value in nm_settings_connection_get_autoconnect_retries().
- use nm_settings_connection_get_autoconnect_retries() in
nm_settings_connection_can_autoconnect().
|
|
|
|
|
|
| |
Split out a separate function _method_call_handle(). That way we can get
rid of the "goto out" and use cleanup attribute to manage resources inside
_method_call_handle().
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Zero is a valid route metric and distinct from -1, which means unspecified.
Fix reader and writer.
Fixes: e374923bbe4a9f608644756f749b9bae9aa5f349
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rename @error to @out_err_str, because @error is usually used for GError
output arguments.
Also, make the string variables "const char *".
Use nm_assert() in read_field(), because it is a static function
with only four call sites. It's easily verified that the assertion
holds, so no need for a run-time check in production builds.
|
|/ |
|
|
|
|
|
|
|
|
| |
Older logfiles contain
platform: route: adding or updating IPv4 route: 10.1.0
Hightlight that too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, after a client performs a connectivity check it cannot
access the up-to-date value of the manager.connectivity property right
away, but it must wait that the queued PropertiesChanged signal is
processed, which is cumbersome.
Arguably, clients already receive the new connectivity value as the
result of the connectivity check call, so they don't have to read it
from the object; however it would be better if the right value of the
object property was available immediately as well.
https://bugzilla.gnome.org/show_bug.cgi?id=784629
|
|
|
|
|
|
|
|
| |
- use nm_utils_addr_family_to_char(). It asserts that the input argument
is either AF_INET or AF_INET6.
- rename variable @family to @addr_family for consistency.
- when logging addr_family for activation-stage, use v4 or v6 instead
of numeric AF_INET/AF_INET6.
|
| |
|