vyos-1x.git/src/conf_mode/policy_route.py, branch feature/T9082-codeql-cpp

Merge pull request #5254 from jd82k/domain-group

2026-06-30T15:05:19+00:00

T8963: policy-route: trigger domain resolver for domain groups

2026-06-08T18:57:28+00:00

Signed-off-by: Miaosen Wang

geoip: T5746: Add GeoIP ASN support

2026-06-04T14:18:29+00:00

geoip: T8590: fix initialization failure and set clobbering on boot and commit

2026-05-19T21:33:48+00:00

Three related bugs prevented GeoIP nftables sets from being populated correctly at boot and when incrementally modifying firewall or policy route rules. 1. geoip_updated() always returned False The previous implementation called node_changed() and then searched the result with dict_search_recursive(changes, 'geoip'). This could never match: node_changed() is annotated `-> list` and returns a flat list of the immediate top-level child names whose subtree changed (e.g. ['ipv4'] for the firewall path, or route names for policy route). The 'geoip' key sits several levels deeper than those names, so dict_search_recursive — which only walks dicts and lists for a matching dict key — never yielded a hit, and geoip_updated() always returned False. As a consequence, geoip_update() was never triggered by an incremental add or change of a GeoIP rule; the only path that ever populated /run/nftables-geoip.conf was the explicit \"update geoip\" command or the fallback when geoip_refresh() failed. Fix: bypass node_changed() and call get_config_diff() / get_child_nodes_diff() directly with expand_nodes=Diff.ADD|Diff.DELETE and recursive=True. In that mode, the 'add' and 'delete' values in the returned dict are full nested subtrees of the config diff, so dict_search_recursive correctly finds 'geoip' wherever it appears in the change set. 2. GeoIP block executed unconditionally, breaking the boot sequence geoip_sets() always returns {'name': [], 'ipv6_name': []}. A non-empty dict is truthy in Python regardless of whether its values are empty lists, so the guards \"if geoip_sets:\" and \"if 'name' in geoip_sets:\" were always True. On boot, when policy_route.py is invoked as a dependent of firewall.py (triggered by group_resync), it entered the GeoIP block even with no policy route GeoIP rules configured. Because /run/nftables-geoip.conf did not yet exist, geoip_refresh() returned False and geoip_update(policy=policy) was called with an empty policy. This created /run/nftables-geoip.conf containing only empty table stubs. When firewall.py subsequently called geoip_refresh(), the file existed and nft loaded it successfully — so the geoip_update(firewall) call was never reached and the firewall GeoIP sets stayed empty for the entire uptime of the router. Fix: check the actual list contents instead of the container dict: if geoip_sets['name'] or geoip_sets['ipv6_name']. 3. geoip_update() clobbered the other caller's sets geoip_update() renders /run/nftables-geoip.conf from both firewall_sets and policy_sets in a single pass. When called with only one argument (as firewall.py and policy_route.py each do), the other argument defaulted to None and that half of the file was rendered empty, erasing whatever the other script had written. The geoip-update helper used by \"update geoip\" and the weekly cron was unaffected because it always passes both arguments, which masked this bug in normal manual operation. Fix: when either argument is absent, read the missing config from the live Config session before building the set tables, so every invocation writes the complete combined firewall + policy file.

T8379: PBR commit fail with traceback if non-existing VRF added

2026-03-23T12:29:11+00:00

geoip: T7926: Refactor geoip handling

2026-01-21T10:52:29+00:00

* Move core logic to separate vyos.geoip module * Use a sqlite database for storing and querying address ranges by country * Remove downloaded geoip ranges once loaded into sqlite db * No longer rebuild geoip sets on each commit unless necessary * Allows for extensibility using other geoip data vendors

T7591: remove copyright years from source files

2025-06-28T21:16:52+00:00

The legal team says years are not necessary so we can go ahead with it, since it will simplify backporting. Automatically removed using: git ls-files | grep -v libvyosconfig | xargs sed -i -E \ 's/^# Copyright (19|20)[0-9]{2}(-[0-9]{4})? VyOS maintainers.*/# Copyright VyOS maintainers and contributors /g' In addition we will error-out during "make" if someone re-adds a legacy copyright notice

geoip: T5636: Add geoip for policy route/route6

2025-03-28T07:47:24+00:00

pbr: T6430: refactor to use vyos.utils.network.get_vrf_tableid()

2024-07-30T06:07:29+00:00

Commit 452068ce78 ("interfaces: T6592: moving an interface between VRF instances failed") added a similar but more detailed implementation of get_vrf_table_id() that was added in commit adeac78ed of this PR. Move to the common available implementation.

pbr: T6430: Allow forwarding into VRFs by name as well as route table IDs

2024-07-30T03:48:18+00:00

* PBR can only target table IDs up to 200 and the previous PR to extend the range was rejected * PBR with this PR can now also target VRFs directly by name, working around targeting problems for VRF table IDs outside the overlapping 100-200 range * Validation ensures rules can't target both a table ID and a VRF name (internally they are handled the same) * Added a simple accessor (get_vrf_table_id) for runtime mapping a VRF name to table ID, based on vyos.ifconfig.interface._set_vrf_ct_zone(). It does not replace that usage, as it deliberately does not handle non-VRF interface lookups (would fail with a KeyError). * Added route table ID lookup dict, global route table and VRF table defs to vyos.defaults. Table ID references have been updated in code touched by this PR. * Added a simple smoketest to validate 'set vrf' usage in PBR rules