Commit Graph

30164 Commits

Author SHA1 Message Date
Thomas Haller
069089cdf2 tools: fix constructing XML by dropping broken pretty_xml()
I don't understand the code, but it mangles the XML.

There is no difference in the markup we have so far. But if you
have nested XML (like for description-docbook tag) there are cases
where this is wrong.

There is also no need to prettify anything. If you want pretty-formatted
XML, do it yourself, for example with

  $ tidy --indent yes --indent-spaces 4 --indent-attributes yes --wrap-attributes yes --input-xml yes --output-xml yes src/libnm-client-impl/nm-property-infos-nmcli.xml

I think this was initially done, because we had the tool in perl, and
when migrating, we wanted to generate the exactly same output. And it
was the same output, and it was fine for the input we have. But with
different input, it's wrong. Drop it now.

(cherry picked from commit 35599b4349)
2022-02-10 08:41:19 +01:00
Thomas Haller
f21cb3065e tools: re-use regular expression in process_data()
Yes, they get cached by the library already. Still, no need for
doing this repeatedly.

(cherry picked from commit 41a177486b)
2022-02-10 08:41:19 +01:00
Thomas Haller
d07e869285 libnm: allow configuring blackhole/unreachable/prohibit routes
(cherry picked from commit 84598adddf)
2022-02-10 08:41:19 +01:00
Thomas Haller
07bdf58856 core/l3cfg: let NML3Cfg handle nodev (blackhole) routes
Certain route types (blackhole, unreachable, prohibit) are not tied to
an interface. They are thus global and we need to track them system wide
(or better: per network namespace). That is done by NMPRouteManager.

For the routing rules, it's NMDevice itself to track/untrack the rules.
That is done for historical reasons, at the time, NML3Cfg did not exit.
Now with NML3Cfg, it seems that also NML3Cfg should be the part that
handles nodev routes. One reason is that we want to move IP
functionality out of NMDevice. So callers (NMDevice) would just add
blackhole routes to the NML3ConfigData and let NML3Cfg handle them.

Still, to handle these routes is rather different from regular routes.
Normally, NML3Cfg tracks an object state (ObjStateData) for each address/route,
and it hooks into platform signals to update the os_plobj field. Those signals
are dispatched by NMNetns and are only per-ifindex. Hence, NML3Cfg
wouldn't be notified about those nodev routes. Consequently, there
os_plobj could not be (efficiently) maintained and there is no
ObjStateData for such routes.

Instead, all that NML3Cfg does is have the routes in the NML3ConfigData and
tell NMPRouteManager about them. Seems simple enough. The only question
is when should NMPRouteManager sync? For now, we sync when the
track/untracking brings any changes and during reapply. Which is
probably fine.

(cherry picked from commit 9ab53e561a)
2022-02-10 08:41:19 +01:00
Thomas Haller
76ba68beb8 core: handle blackhole/unreachable/prohibit route types in core
Specifically, in nm_utils_ip_route_attribute_to_platform() and in
_l3_config_data_add_obj() handle such new route type. For the moment,
they cannot be stored in a valid NMSettingIPConfig, but later this will
be necessary.

(cherry picked from commit 6255e0dcac)
2022-02-10 08:41:19 +01:00
Thomas Haller
87f4612e53 core/l3cfg: rework generating list of routes in _l3_commit_one()
This will be required next, when we will have also routes without a
device. Split the generation of the route list out.

(cherry picked from commit e32bc6d248)
2022-02-10 08:41:18 +01:00
Thomas Haller
5ca61db640 platform: improve way to prune dirty route-manager entries
The general idea is that when we have entries tracked by the
route-manager, that we can mark them all as dirty. Then, calling the
"track" function will reset the dirty flag. Finally, there is a method
to delete all dirty entries.

As we can lookup an entry with O(1) (using dictionaries), we can
sync the list of tracked objects with O(n). We just need to track
all the ones we care about, and then delete those that were not touched
(that is, are still dirty).

Previously, we had to explicitly mark all entries as dirty. We can do
better. Just let nmp_route_manager_untrack_all() mark the survivors as
dirty right away. This way, we can save iterating the list once.

It also makes sense because the only purpose of the dirty flag is to
aid this prune mechanism with track/untrack-all. So, untrack-all can
just help out, and leave the remaining entries dirty, so that the next
track does the right thing.

(cherry picked from commit 9e90bb0817)
2022-02-10 08:41:18 +01:00
Thomas Haller
0dab9404a4 platform: return boolean changed value from nmp_route_manager_track()
(cherry picked from commit 5489aa596b)
2022-02-10 08:41:18 +01:00
Thomas Haller
16b3522d51 platform: return self from nmp_route_manager_ref()
It's just more convenient.

(cherry picked from commit 81f6ba8377)
2022-02-10 08:41:18 +01:00
Thomas Haller
d33d8f1250 platform: track linked list of objects in NMPRouteManager by type
We now track up to three kinds of object types in NMPRouteManager.

There is only one place, where we need to iterate over all objects of
the same type (e.g. all ipv4-routes), and that is nmp_route_manager_sync().

Previously, we only had one GHashTable with all the object, and when
iterating we had to skip over them after checking the type. That has some
overhead, but OK.

The ugliness with iterating over a GHashTable is that the order is non
deterministic. We should have a defined order in which things happen. To
achieve that, track three different CList, one for each object type.
Also, I expect that to be slightly faster, as you only have to iterate
over the list you care about.

(cherry picked from commit f315ca9e84)
2022-02-10 08:41:18 +01:00
Thomas Haller
dab70027e6 platform: extend NMPRouteManager to work for routes
(cherry picked from commit 7c27c63bec)
2022-02-10 08:41:18 +01:00
Thomas Haller
506590ff66 platform: use nm_pdirect_{hash,equal}() in "nmp-route-manager.c"
No need for a dedicated implementation just to compare two
indirect pointers.

(cherry picked from commit 2e04d64232)
2022-02-10 08:41:18 +01:00
Thomas Haller
7a80400d7d platform: use nm_g_slice_free() in "nmp-route-manager.c"
(cherry picked from commit cfdecf5e96)
2022-02-10 08:41:18 +01:00
Thomas Haller
f4a33bd5c0 platform: use NM_HASH_OBFUSCATE_PTR() in "nmp-route-manager.c"
NM_HASH_OBFUSCATE_PTR() is some snake-oil to not log raw pointer values.
It obviously makes debugging harder.

But we don't need to generate differently obfuscated pointer values.
At least, let most users use the same obfuscation, so that the values
are comparable.

(cherry picked from commit 3e6c8d220a)
2022-02-10 08:41:17 +01:00
Thomas Haller
cc7a13c295 platform: use __NMLOG_DEFAULT() in "nmp-route-manager.c"
(cherry picked from commit 1baa301047)
2022-02-10 08:41:17 +01:00
Thomas Haller
aea447ac71 platform: rename internals in "nmp-route-manager.c"
We will not only track (routing) rules, but also routes. Rename.

(cherry picked from commit 75959e2f1a)
2022-02-10 08:41:17 +01:00
Thomas Haller
ca2de61dcc platform: drop lazy initialization _rules_init() of NMPRouteManager
Let's just always allocate the hash tables. We will likely need them,
and three hash tables are relatively cheap.

(cherry picked from commit 5b3e96451b)
2022-02-10 08:41:17 +01:00
Thomas Haller
78add254a1 platform: rename "nmp-route-manager.h" to "nmp-rules-manager.h"
(cherry picked from commit 3996933c57)
2022-02-10 08:41:17 +01:00
Thomas Haller
e69e5d5446 platform: rename NMPRulesManager API to NMPRouteManager
Routes of type blackhole, unreachable, prohibit don't have an
ifindex/device. They are thus in many ways similar to routing rules,
as they are global. We need a mediator to keep track which routes
to configure.

This will be very similar to what NMPRulesManager already does for
routing rules. Rename the API, so that it also can be used for routes.

Renaming the file will be done next, so that git's rename detection
doesn't get too confused.

(cherry picked from commit ea4f6d7994)
2022-02-10 08:41:17 +01:00
Thomas Haller
a2030c01ce platform: add support for blackhole,unreachable,prohibit route type
(cherry picked from commit 92f51c6b43)
2022-02-10 08:41:17 +01:00
Thomas Haller
bd08f8e81c platform: add nm_platform_route_type_is_nodev() helper
(cherry picked from commit 7ad14b86f8)
2022-02-10 08:41:16 +01:00
Thomas Haller
2394a93944 platform: don't treat ifindex zero special in nmp_lookup_init_object()
So far, certain NMObject types could not have an ifindex of zero. Hence,
nmp_lookup_init_object() took such an ifindex to mean lookup all objects
of that type.

Soon, we will support blackhole/unreachable/prohibit route types, which
have their ifindex set to zero. It is still useful to lookup those routes
types via nmp_lookup_init_object().

Change behaviour how to interpret the ifindex. Note that this also
affects various callers of nmp_lookup_init_object(). If somebody was
relying on the previous behavior, it would need fixing.

(cherry picked from commit d4ad9666bd)
2022-02-10 08:41:16 +01:00
Thomas Haller
5c31184585 platform: don't check for valid ifindex in _vt_cmd_obj_is_alive_ipx_route()
_vt_cmd_obj_is_alive_ipx_route() is called by nmp_object_is_alive().
Non-alive objects are not put into the cache.

That certainly makes sense for RTM_F_CLONED routes, because they are
generated ad-hoc during the `ip route get` request.

Checking for the ifindex is not necessary. For one, some route types
(blackhole, unreachable, prohibit) don't have an ifindex. Also, the
purpose of _vt_cmd_obj_is_alive_ipx_route() is not to validate the
object. Just don't create objects without an ifindex, if you think the
route needs an ifindex. Checking here is not useful.

We also don't check that other fields like rt_source are valid, so there
is no need to do it for the ifindex either.

(cherry picked from commit 1123d3a5fb)
2022-02-10 08:41:16 +01:00
Thomas Haller
1853d53425 platform: don't print NUL gateway in nm_platform_ip[46]_route_to_string()
Currently, for NMPlatformIP[46]Route always has a gateway, even if it's
possibly set to 0.0.0.0/::. Not sure whether kernel has a further
distinction between no-gateway and all-zero gateway.

Anyway. For us, a gateway of 0.0.0.0/:: means the same as having no
gateway. We cannot differentiate the two (nor do we need to).

Don't print that in nm_platform_ip[46]_route_to_string().

Also, because we are going to add blackhole route types, which cannot
have a next-hop. But we do this change for all routes types, because
it makes sense in general (and also what `ip route show` prints).

(cherry picked from commit b58711f20d)
2022-02-10 08:41:16 +01:00
Thomas Haller
2eaf8d7048 core: use IS_IPv4 variable in nm_utils_ip_route_attribute_to_platform()
It's what we do at many other places. Consistency.

(cherry picked from commit 596d1645e8)
2022-02-10 08:41:16 +01:00
Thomas Haller
eec32669a9 platform: rename variable "IS_IPv4" in platform code
The variable with this purpose is usually called "IS_IPv4".

It's upper case, because usually this is a const variable, and because
it reminds of the NM_IS_IPv4(addr_family) macro. That letter case
is unusual, but it makes sense to me for the special purpose that this
variable has.

Anyway. The naming of this variable is a different point. Let's
use the variable name that is consistent and widely used.

(cherry picked from commit 8085c0121f)
2022-02-10 08:41:16 +01:00
Thomas Haller
9259ac065f libnm: rework validating route attributes to avoid duplicate check
_nm_ip_route_attribute_validate_all() validates all attributes together.
As such, it calls to nm_ip_route_attribute_validate(), which in turn
validates one attribute at a time.

Such full validation needs to check that (potentially conflicting)
attributes are valid together. Hence, _nm_ip_route_attribute_validate_all()
needs again peek into the attributes.

Refactor the code, so that we can extract the pieces that we need and
not need to parse them twice.

(cherry picked from commit 0413b1bf8a)
2022-02-10 08:41:16 +01:00
Thomas Haller
70c2478f89 libnm: change NMVariantAttributeSpec.str_type to work for attributes of any type
First of all, all of NMVariantAttributeSpec is internal API. We only
expose the typedef itself as public API, but not its fields nor
their meaning. So we can change things.

Change "str_type" to "type_detail", so that it can work for any kind of
attribute, not only for strings. Usually, we want to avoid special
cases and treat all attributes the same, based on their GVariant type.
But sometimes, it is necessary to do something special with an
attribute. This is what the "type_detail" encodes, but it's not only
relevant for strings.

(cherry picked from commit 6f277d8fa6)
2022-02-10 08:41:16 +01:00
Thomas Haller
11d4d244dd libnm: avoid parsing IP addresses twice in NMIPAddress/NMIPRoute API
Usually the normalization (canonicalize) and validation of the IP
address string both requires to parse the string. As we always do
validation first, we can use the parsed address and don't need to parse
it a second time.

(cherry picked from commit 00e4f21629)
2022-02-10 08:41:16 +01:00
Thomas Haller
beca3a4d46 libnm: reorder fields in NMIPAddress/NMIPRoute struct
Order the fields by their size, to minimize the alignment gaps.
I guess, that doesn't matter because the alignment of the heap
allocation is larger than what we can safe here. Still, there is
on reason to do it any other way.

Also, it's not possible via API to set family/prefix to values outside
their range, so an 8bit integer is always sufficient. And we don't want
that invariant to change. We don't ever want to allow the caller to set
values that are clearly invalid, and will assert against that early (g_return()).
Point is, we can do this and there is no danger of future problems.
And even if we will support larger values, it's all an implementation
detail anyway.

(cherry picked from commit 6208a1bb84)
2022-02-10 08:41:15 +01:00
Thomas Haller
1701048e02 tests: let "run-nm-test.sh" fail with exit code 1 on failure
`git bisect run` is peculiar about the exit code:

  error: bisect run failed: exit code 134 from '...' is < 0 or >= 128

If we just "exec" the test, it usually will fail on an assert. That results
in SIGABRT or exit code 134. So out of the box that is annoying with
git-bisect.

Work around that and let the test wrapper always coerce any test failure
to exit code 1.

(cherry picked from commit f65747f6e9)
2022-02-10 08:41:15 +01:00
Thomas Haller
d9fbfad9f4 libnm,core: merge branch 'th/route-blackhole'
https://bugzilla.redhat.com/show_bug.cgi?id=1937823
https://bugzilla.redhat.com/show_bug.cgi?id=2013587

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1083
2022-02-10 08:39:53 +01:00
Thomas Haller
948c2b0fb1 libnm/doc: describe routing-rules in man nm-settings-nmcli 2022-02-09 23:10:58 +01:00
Thomas Haller
7b1e9a5c3d libnm/doc: list route attributes in man nm-settings-nmcli
IPv4:

       routes
           A list of IPv4 destination addresses, prefix length, optional IPv4
           next hop addresses, optional route metric, optional attribute. The
           valid syntax is: "ip[/prefix] [next-hop] [metric]
           [attribute=val]...[,ip[/prefix]...]". For example "192.0.2.0/24
           10.1.1.1 77, 198.51.100.0/24".

           Various attributes are supported:

           •   "cwnd" - an unsigned 32 bit integer.

           •   "initcwnd" - an unsigned 32 bit integer.

           •   "initrwnd" - an unsigned 32 bit integer.

           •   "lock-cwnd" - a boolean value.

           •   "lock-initcwnd" - a boolean value.

           •   "lock-initrwnd" - a boolean value.

           •   "lock-mtu" - a boolean value.

           •   "lock-window" - a boolean value.

           •   "mtu" - an unsigned 32 bit integer.

           •   "onlink" - a boolean value.

           •   "scope" - an unsigned 8 bit integer. IPv4 only.

           •   "src" - an IPv4 address.

           •   "table" - an unsigned 32 bit integer. The default depends on
               ipv4.route-table.

           •   "tos" - an unsigned 8 bit integer. IPv4 only.

           •   "type" - one of unicast, local, blackhole, unavailable,
               prohibit. The default is unicast.

           •   "window" - an unsigned 32 bit integer.

           For details see also `man ip-route`.

           Format: a comma separated list of routes

IPv6:

       routes
           A list of IPv6 destination addresses, prefix length, optional IPv6
           next hop addresses, optional route metric, optional attribute. The
           valid syntax is: "ip[/prefix] [next-hop] [metric]
           [attribute=val]...[,ip[/prefix]...]".

           Various attributes are supported:

           •   "cwnd" - an unsigned 32 bit integer.

           •   "from" - an IPv6 address with optional prefix. IPv6 only.

           •   "initcwnd" - an unsigned 32 bit integer.

           •   "initrwnd" - an unsigned 32 bit integer.

           •   "lock-cwnd" - a boolean value.

           •   "lock-initcwnd" - a boolean value.

           •   "lock-initrwnd" - a boolean value.

           •   "lock-mtu" - a boolean value.

           •   "lock-window" - a boolean value.

           •   "mtu" - an unsigned 32 bit integer.

           •   "onlink" - a boolean value.

           •   "src" - an IPv6 address.

           •   "table" - an unsigned 32 bit integer. The default depends on
               ipv6.route-table.

           •   "type" - one of unicast, local, blackhole, unavailable,
               prohibit. The default is unicast.

           •   "window" - an unsigned 32 bit integer.

           For details see also `man ip-route`.

           Format: a comma separated list of routes
2022-02-09 22:33:23 +01:00
Thomas Haller
35599b4349 tools: fix constructing XML by dropping broken pretty_xml()
I don't understand the code, but it mangles the XML.

There is no difference in the markup we have so far. But if you
have nested XML (like for description-docbook tag) there are cases
where this is wrong.

There is also no need to prettify anything. If you want pretty-formatted
XML, do it yourself, for example with

  $ tidy --indent yes --indent-spaces 4 --indent-attributes yes --wrap-attributes yes --input-xml yes --output-xml yes src/libnm-client-impl/nm-property-infos-nmcli.xml

I think this was initially done, because we had the tool in perl, and
when migrating, we wanted to generate the exactly same output. And it
was the same output, and it was fine for the input we have. But with
different input, it's wrong. Drop it now.
2022-02-09 20:26:34 +01:00
Thomas Haller
41a177486b tools: re-use regular expression in process_data()
Yes, they get cached by the library already. Still, no need for
doing this repeatedly.
2022-02-09 20:26:22 +01:00
Thomas Haller
84598adddf libnm: allow configuring blackhole/unreachable/prohibit routes 2022-02-09 19:13:05 +01:00
Thomas Haller
9ab53e561a core/l3cfg: let NML3Cfg handle nodev (blackhole) routes
Certain route types (blackhole, unreachable, prohibit) are not tied to
an interface. They are thus global and we need to track them system wide
(or better: per network namespace). That is done by NMPRouteManager.

For the routing rules, it's NMDevice itself to track/untrack the rules.
That is done for historical reasons, at the time, NML3Cfg did not exit.
Now with NML3Cfg, it seems that also NML3Cfg should be the part that
handles nodev routes. One reason is that we want to move IP
functionality out of NMDevice. So callers (NMDevice) would just add
blackhole routes to the NML3ConfigData and let NML3Cfg handle them.

Still, to handle these routes is rather different from regular routes.
Normally, NML3Cfg tracks an object state (ObjStateData) for each address/route,
and it hooks into platform signals to update the os_plobj field. Those signals
are dispatched by NMNetns and are only per-ifindex. Hence, NML3Cfg
wouldn't be notified about those nodev routes. Consequently, there
os_plobj could not be (efficiently) maintained and there is no
ObjStateData for such routes.

Instead, all that NML3Cfg does is have the routes in the NML3ConfigData and
tell NMPRouteManager about them. Seems simple enough. The only question
is when should NMPRouteManager sync? For now, we sync when the
track/untracking brings any changes and during reapply. Which is
probably fine.
2022-02-09 19:13:05 +01:00
Thomas Haller
6255e0dcac core: handle blackhole/unreachable/prohibit route types in core
Specifically, in nm_utils_ip_route_attribute_to_platform() and in
_l3_config_data_add_obj() handle such new route type. For the moment,
they cannot be stored in a valid NMSettingIPConfig, but later this will
be necessary.
2022-02-09 19:13:05 +01:00
Thomas Haller
e32bc6d248 core/l3cfg: rework generating list of routes in _l3_commit_one()
This will be required next, when we will have also routes without a
device. Split the generation of the route list out.
2022-02-09 19:13:05 +01:00
Thomas Haller
9e90bb0817 platform: improve way to prune dirty route-manager entries
The general idea is that when we have entries tracked by the
route-manager, that we can mark them all as dirty. Then, calling the
"track" function will reset the dirty flag. Finally, there is a method
to delete all dirty entries.

As we can lookup an entry with O(1) (using dictionaries), we can
sync the list of tracked objects with O(n). We just need to track
all the ones we care about, and then delete those that were not touched
(that is, are still dirty).

Previously, we had to explicitly mark all entries as dirty. We can do
better. Just let nmp_route_manager_untrack_all() mark the survivors as
dirty right away. This way, we can save iterating the list once.

It also makes sense because the only purpose of the dirty flag is to
aid this prune mechanism with track/untrack-all. So, untrack-all can
just help out, and leave the remaining entries dirty, so that the next
track does the right thing.
2022-02-09 19:13:05 +01:00
Thomas Haller
5489aa596b platform: return boolean changed value from nmp_route_manager_track() 2022-02-09 19:13:05 +01:00
Thomas Haller
81f6ba8377 platform: return self from nmp_route_manager_ref()
It's just more convenient.
2022-02-09 19:13:04 +01:00
Thomas Haller
f315ca9e84 platform: track linked list of objects in NMPRouteManager by type
We now track up to three kinds of object types in NMPRouteManager.

There is only one place, where we need to iterate over all objects of
the same type (e.g. all ipv4-routes), and that is nmp_route_manager_sync().

Previously, we only had one GHashTable with all the object, and when
iterating we had to skip over them after checking the type. That has some
overhead, but OK.

The ugliness with iterating over a GHashTable is that the order is non
deterministic. We should have a defined order in which things happen. To
achieve that, track three different CList, one for each object type.
Also, I expect that to be slightly faster, as you only have to iterate
over the list you care about.
2022-02-09 19:13:04 +01:00
Thomas Haller
7c27c63bec platform: extend NMPRouteManager to work for routes 2022-02-09 19:13:04 +01:00
Thomas Haller
2e04d64232 platform: use nm_pdirect_{hash,equal}() in "nmp-route-manager.c"
No need for a dedicated implementation just to compare two
indirect pointers.
2022-02-09 19:13:04 +01:00
Thomas Haller
cfdecf5e96 platform: use nm_g_slice_free() in "nmp-route-manager.c" 2022-02-09 19:13:04 +01:00
Thomas Haller
3e6c8d220a platform: use NM_HASH_OBFUSCATE_PTR() in "nmp-route-manager.c"
NM_HASH_OBFUSCATE_PTR() is some snake-oil to not log raw pointer values.
It obviously makes debugging harder.

But we don't need to generate differently obfuscated pointer values.
At least, let most users use the same obfuscation, so that the values
are comparable.
2022-02-09 19:13:04 +01:00
Thomas Haller
1baa301047 platform: use __NMLOG_DEFAULT() in "nmp-route-manager.c" 2022-02-09 19:13:04 +01:00
Thomas Haller
75959e2f1a platform: rename internals in "nmp-route-manager.c"
We will not only track (routing) rules, but also routes. Rename.
2022-02-09 19:13:04 +01:00