| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Initscripts added support for arbitrary VLAN id using a variable
different from NM's:
https://github.com/fedora-sysv/initscripts/commit/368d19d31a057bf4d82ba428629694618edce133
Let's write both the NM (VLAN_ID) and initscripts (VID) variable. This
is ugly.
|
|
|
|
|
|
|
|
| |
Initscripts require DEVICE to be set for VLANs, so always write the
variable when we know the parent interface name.
To determine if connection.interface-name is actually set in the NM
connection, use a new NM_IGNORE_DEVICE variable. This is ugly.
|
|
|
|
| |
The setting name is NMSettingBond.
|
|
|
|
|
| |
The plugin already writes DEVICE in write_connection_setting(), there
is no need to write it again elsewhere.
|
|
|
|
|
|
|
|
| |
Previously when the interface created by pppd was already the one we
expected, we would rename it to itself and remove the device from the
manager. Don't do it.
Fixes: 6c3195931e94cab70208ce97f3b834f5d9f5ff62
|
|\
| |
| |
| |
| |
| | |
Drop NMDefaultRouteManager.
https://github.com/NetworkManager/NetworkManager/pull/26
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove NMDefaultRouteManager. Instead, add the default-route to the
NMIP4Config/NMIP6Config instance.
This basically reverts commit e8824f6a5205ffcf761abd3e0897a22b254c7797.
We added NMDefaultRouteManager because we used the corresponding to `ip
route replace` when configuring routes. That would replace default-routes
on other interfaces so we needed a central manager to coordinate routes.
Now, we use the corresponding of `ip route append` to configure routes,
and each interface can configure routes indepdentently.
In NMDevice, when creating the default-route, ignore @auto_method for
external devices. We shall not touch these devices.
Especially the code in NMPolicy regarding selection of the best-device
seems wrong. It probably needs further adjustments in the future.
Especially get_best_ip_config() should be replaced, because this
distinction VPN vs. devices seems wrong to me.
Thereby, remove the @ignore_never_default argument. It was added by
commit bb750260045239ab85574366bae8102eff8058cc, I don't think it's
needed anymore.
This brings another change. Now that we track default-routes in
NMIP4Config/NMIP6Config, they are also exposed on D-Bus like regular
routes. I think that makes sense, but it is a change in behavior, as
previously such routes were not exposed there.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Default-routes are for the most part like regular routes. Add support to
track them like regular routes in NMIP4Config/NMIP6Config.
One thing is, sometimes we need to figure out whether an ip-config
instance has a default-route. For that, keep track of the best
default-route (there might be multiple) and expose it. That is
the most complicated part of this patch, because there are so many
places where the list of routes gets modified (replace, intersect,
subtract, merge, add), and they all need to take care of updating
the best default-route.
In a next patch, NMDefaultRouteManager will be dropped and default-routes
will be tracked by NMIP4Config/NMIP6Config.
|
|\
| |
| |
| |
| |
| |
| | |
Several patches with cleanup and in prepration for dropping
NMDefaultRouteManager.
https://github.com/NetworkManager/NetworkManager/pull/26
|
| |
| |
| |
| |
| | |
Later we will need the exact instance that we just added (or the previously
existing one, if the new route is already tracked).
|
| |
| |
| |
| | |
_nmtst_ip*_config_*()
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we would first delete routes that are not to be added,
before adding the new ones.
This has the advantage, that even if delete removes the wrong route,
add would restore the expected state. This tries to workaround the fact
that RTM_DELROUTE allows for wild-card fields, and might delete the
wrong route.
However, for example when bumping the route metric after connectivty
check (removing the default-route with metric 20100 and adding the one
with metric 100), there is a short moment when there is no
default-route.
To avoid that, don't do delete-then-add, but add-then-delete.
|
| |
| |
| |
| | |
and nm_ip6_config_capture().
|
| |
| |
| |
| | |
and nm_ip6_config_capture().
|
| |
| |
| |
| | |
Taken from "src/nm-default-route-manager.c".
|
| |
| |
| |
| | |
Will be used later.
|
| |
| |
| |
| |
| | |
Functions that take and addr_family argument are just nicer
to use at places where we treat IPv4 and IPv6 generically.
|
| | |
|
| |
| |
| |
| | |
Will be used later.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid calling nm_dedup_multi_index_add() directly, like we do for all other places.
Instead, call the wrapper _nm_ip_config_add_obj() which does some pre-precessing.
In practice, the result is exactly the same (at the moment). But there should by
only one way to add the route.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Don't rely on manager keeping them alive long enough. E.g.
get-best-device() is used when resetting the best device,
however, it accesses the current device (hence, it relies
on manager removing the device from the list, but keeping
it alive long enough).
|
| |
| |
| |
| |
| | |
- _LOGt() whenever the properties change.
- some minor refactoring
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already track the best device as priv->default_device4 / priv->default_device6.
Don't try to look it up again. If the cached values from @priv are invalid/outdated,
that should be fixed instead.
This was already introduced by commit 773c006a4c9d3162e9b371762dc59fd5948e4b43.
But I don't think it should be done.
|
| |
| |
| |
| |
| | |
There is no reason for if-else-if. If DHCPv4 doesn't provide a hostname (but we
are doing DHCP), just check for DHCPv6.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- nm_clear_g_object() is like g_clear_object() but:
- it returns a boolean value, indicating that something was cleared.
- it includes an nm_assert() to check that the pointer is still
valid.
- it uses typeof() instead of blindly casting the argument.
- nm_g_object_ref_set() combines nm_clear_g_object() and resetting
the pointer to a new object, including taking a reference.
- also returns a boolean, indicating whether something changed.
- it gets the order of operations right: first it increses the
ref-count, before unrefing the old object.
- like nm_clear_g_object() and nm_clear_g_free() it first sets
the destination to NULL, instead of leaving a dangling pointer
for the duraction of the unref/free call.
- fix nm_clear_g_free() not to use a possibly dangling pointer.
Striclty speaking, that is undefined behavior.
|
|
|
|
|
|
| |
And relax the type for nm_auto_unref_gtypeclass macro. Like
g_type_class_unref() itself, you usually don't use it with a GTypeClass
base class, but some subtype like GObjectClass.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787378
|
|
|
|
|
| |
There are many places where the function can fail without returning an
error, leading to a crash. Fix this.
|
|
|
|
|
| |
I find it annoying when ^C exits less and it prompts me to often
do `NM-log | less -R` instead.
|
|
|
|
|
| |
Must not colorize the trailing space, otherwise the following
" device" will no longer match.
|
|
|
|
|
|
|
|
| |
- remove "\r\n" line endings
- colorize <warn> and <error> in red
- extend matching the info levels to include the timestamp. This
(intentionally) will no longer highlight messages from ModemManager,
which don't include a timestamp.
|
|
|
|
|
|
|
|
|
|
| |
- use "grep -a" so that grep doesn't refuse to work in binary input.
- make the script source-able to only define the NM-colorize and
NM-show-journal
- In case the script is sourced, it also defines a NM-log function,
which does the same as the script itself.
- rename internal functions so that they have names starting with "NM"
in case of sourcing.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787382
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787380
|
|\
| |
| |
| |
| |
| | |
Fix and improve determining the route to the external VPN gateway.
https://bugzilla.gnome.org/show_bug.cgi?id=787370
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Until recently, we would only consier the IP config of the parent device
to determine the route to the external VPN gateway. We changed that, to
additionally improve the guess by letting kernel resolve the route.
Now, drop checking the parent's config entirely. The only thing that
matters is the here and now runtime configuraion on the parent device.
And for that we ask kernel to resolve the route.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we would try to resolve the route in general (unrestricted
to a certain ifindex), and reject it the result wasn't on the parent
device.
Now, use the oif argument, and resolve the route only on the parent device.
The problem is that kernel would pretend that the destination is onlink, if
there is no route to it. Hence, hack around that by only accepting an onlink
route, if the VPN gateway itself is site-local. Yes, there are scenarios where
this will still lead to a wrong guess. See related bug rh#1489343 for kernel.
|
| |
| |
| |
| | |
Analog to `ip route get $DST oif $IFACE`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In practice, it shouldn't matter much, because NM may frequently
reapply the IP config. Hence, it anyway must cope with the fact that
IP config from a previous iteration is already applied on the VPN device,
before applying it to the parent device.
Anyway, it makes a bit more sense to apply it first the the parent device.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating the NMIP4Config/NMIP6Config instance, we must always use the right
ifindex. That is the ifindex, on which we want to apply the config. It also means,
that for device-based VPNs (those with priv->ip_ifindex set, like OpenVPN), the
parent's config must have the ip-ifindex of the parent device. Not of the
VPN's device.
One effect of this bug is that in add_ip4_vpn_gateway_route() we resolve
the route to the external gateway and only accept it if it's on the
parent device. But since the ifindex of the config was wrong, we would accept
route on the wrong interface.
https://bugzilla.gnome.org/show_bug.cgi?id=787370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit 5a69b27a64a0 ("platform: let platform operations only
consider kernel response") the platform only relies on kernel messages
and doesn't check if a deleted object is gone from the cache. For IPv6
addresses it can happen that the RTM_DELADDR comes after the ack, and
this causes random failures in test /address/ipv6/general-2:
[10.8009] platform: address: deleting IPv6 address 2001:db8:a:b:1:2:3:4/64, ifindex 12 dev nm-test-device
[10.8009] platform-linux: delayed-action: schedule wait-for-nl-response (seq 55, timeout in 0.199999680, response-type 0)
[10.8009] platform-linux: delayed-action: handle wait-for-nl-response (any)
[10.8009] platform-linux: netlink: recvmsg: new message (2), flags 0x0100, seq 55
[10.8009] platform-linux: delayed-action: complete wait-for-nl-response (seq 55, timeout in 0.199980533, response-type 0, success)
[10.8009] platform-linux: do-delete-ip6-address[12: 2001:db8:a:b:1:2:3:4]: success
**
NetworkManager:ERROR:src/platform/tests/test-common.c:1127:_ip_address_del: assertion failed: (external_command)
Use the same workaround in place for the addition of IPv6 addresses,
i.e. refetch the object if the address is still present after the ack.
|
| |
|
|
|
|
| |
That is how kernel allows it and the rest of NetworkManager's API.
|
|
|
|
|
| |
It is used for example for the route's metric, which is
guint32 and may not fit into int type.
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1474295
|
| |
| |
| |
| |
| | |
-1 means "unset" to allow fallback to the per-device metric.
That shall be the preferred default.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
based on network class
For RFC1918 private IPv4addresses, guess a better prefix length for
addresses and routes.
nmtui is an interactive program. It makes sense to be a bit smarter
about what the user probably meant.
It would be nice if nmtui would update the entry field immediately when
the cursor leaves the field, to show the guessed prefix length. However,
that is not easily possible, so lets to that another time.
For IPv6 addresses, default to /64 instead of /128.
https://bugzilla.redhat.com/show_bug.cgi?id=1474295
|