1. 13 Feb, 2022 2 commits
  2. 11 Feb, 2022 2 commits
  3. 10 Feb, 2022 9 commits
  4. 09 Feb, 2022 27 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm/doc: list route attributes in `man nm-settings-nmcli` · 7b1e9a5c
      Thomas Haller authored
      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
      7b1e9a5c
    • Thomas Haller's avatar
      tools: fix constructing XML by dropping broken pretty_xml() · 35599b43
      Thomas Haller authored
      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.
      35599b43
    • Thomas Haller's avatar
      tools: re-use regular expression in process_data() · 41a17748
      Thomas Haller authored
      Yes, they get cached by the library already. Still, no need for
      doing this repeatedly.
      41a17748
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      core/l3cfg: let NML3Cfg handle nodev (blackhole) routes · 9ab53e56
      Thomas Haller authored
      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.
      9ab53e56
    • Thomas Haller's avatar
      core: handle blackhole/unreachable/prohibit route types in core · 6255e0dc
      Thomas Haller authored
      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.
      6255e0dc
    • Thomas Haller's avatar
      core/l3cfg: rework generating list of routes in _l3_commit_one() · e32bc6d2
      Thomas Haller authored
      This will be required next, when we will have also routes without a
      device. Split the generation of the route list out.
      e32bc6d2
    • Thomas Haller's avatar
      platform: improve way to prune dirty route-manager entries · 9e90bb08
      Thomas Haller authored
      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.
      9e90bb08
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      platform: return self from nmp_route_manager_ref() · 81f6ba83
      Thomas Haller authored
      It's just more convenient.
      81f6ba83
    • Thomas Haller's avatar
      platform: track linked list of objects in NMPRouteManager by type · f315ca9e
      Thomas Haller authored
      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.
      f315ca9e
    • Thomas Haller's avatar
      7c27c63b
    • Thomas Haller's avatar
      platform: use nm_pdirect_{hash,equal}() in "nmp-route-manager.c" · 2e04d642
      Thomas Haller authored
      No need for a dedicated implementation just to compare two
      indirect pointers.
      2e04d642
    • Thomas Haller's avatar
      cfdecf5e
    • Thomas Haller's avatar
      platform: use NM_HASH_OBFUSCATE_PTR() in "nmp-route-manager.c" · 3e6c8d22
      Thomas Haller authored
      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.
      3e6c8d22
    • Thomas Haller's avatar
      1baa3010
    • Thomas Haller's avatar
      platform: rename internals in "nmp-route-manager.c" · 75959e2f
      Thomas Haller authored
      We will not only track (routing) rules, but also routes. Rename.
      75959e2f
    • Thomas Haller's avatar
      platform: drop lazy initialization _rules_init() of NMPRouteManager · 5b3e9645
      Thomas Haller authored
      Let's just always allocate the hash tables. We will likely need them,
      and three hash tables are relatively cheap.
      5b3e9645
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      platform: rename NMPRulesManager API to NMPRouteManager · ea4f6d79
      Thomas Haller authored
      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.
      ea4f6d79
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      7ad14b86
    • Thomas Haller's avatar
      platform: don't treat ifindex zero special in nmp_lookup_init_object() · d4ad9666
      Thomas Haller authored
      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.
      d4ad9666
    • Thomas Haller's avatar
      platform: don't check for valid ifindex in _vt_cmd_obj_is_alive_ipx_route() · 1123d3a5
      Thomas Haller authored
      _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.
      1123d3a5
    • Thomas Haller's avatar
      platform: don't print NUL gateway in nm_platform_ip[46]_route_to_string() · b58711f2
      Thomas Haller authored
      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).
      b58711f2
    • Thomas Haller's avatar
      core: use IS_IPv4 variable in nm_utils_ip_route_attribute_to_platform() · 596d1645
      Thomas Haller authored
      It's what we do at many other places. Consistency.
      596d1645