Then this task can be set to closed and invalid :-)

If you don't use the firewall (statefully at least) then it will go through the FW_CONNTRACK chain and the NAT_CONNTRACK and/or WLB_CONNTRACK chains will be reached, or fall through to the notrack.

But the NAT_CONNTRACK and WLB_CONNTRACK chains are never evaluted because FW_CONNTRACK always set action to accept?

That is how the conntrack enabling system works. FW_CONNTRACK verdict is set to accept when it is determined the firewall needs conntracking (state rules, flowtable etc.), same for NAT_/WLB_ chains. If none require conntrack - all chains will be return and it falls down the chain to the final notrack and conntrack is not enabled.

An additional "nice to have" would be a hook that runs on route state change.
Examples:

set protocols failover route 0.0.0.0/0 next-hop 100.100.100.1 hook '/config/scripts/failover-hook-100.100.100.1'

PR: https://github.com/vyos/vyos-1x/pull/2357

PR: https://github.com/vyos/vyos-1x/pull/2355

Once PR https://github.com/vyos/vyos-1x/pull/2344 is merged, counters and logs for default action should be available once again.

Problem remains with "N/D" is being used in show firewall groups instead of "None".

Verified in VyOS 1.5-rolling-202310090023:

Works as expected:

PR:
https://github.com/vyos/vyos-1x/pull/2352

Final testing before PR, the following corrects behavior when configuring the http-api using the http-api, for example:

PR created: https://github.com/vyos/vyos-1x/pull/2349

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2347

PR for 1.4 https://github.com/vyos/vyos-1x/pull/2346

PR: https://github.com/vyos/vyos-1x/pull/2344

Added for 1.4, 1.5; as mentioned above, a backport to Equuleus will require a different implementation.

Based on the requirements, it is natural to add this to the commit_revision post-commit hook of the config_mgmt module: this is low overhead as we use the existing configtree representation of the current config to save with ConfigTree().to_json().

@rherold Could you re-check it?

for me , it's ok . I didn't see another issue related it . we can close

PRs:
https://github.com/vyos/vyos-1x/pull/2338
https://github.com/vyos/vyatta-cfg-system/pull/210

@indrajitr Thanks!

Can we close it?

Applied to current and sagitta

Can we close it?

@indrajitr, Could you re-check and close if it was solved?

PR created: https://github.com/vyos/vyos-build/pull/434

Regarding STRIP_EXCLUDE variable... one idea is to assign it dynamically like so:

Proposed CLI:

set system syslog global service wireguard

Expected command for debug

echo "module wireguard +p" | sudo tee /sys/kernel/debug/dynamic_debug/control

To disable

echo "module wireguard -p" | sudo tee /sys/kernel/debug/dynamic_debug/control

PR https://github.com/vyos/vyos-user-utils/pull/7

vyos@r4# echo '{"system": "VyOS", "rate": 100}' | jq '.system'
"VyOS"
[edit]
vyos@r4#

@xrobau noted that PR426 have an anomaly regarding one of the libraries during the strip-run:

Just to confirm, changing the if line does solve the issue, and I am able to log in.

Out of curiosity, shouldn't this just be moved to the end of the startup scripts?

Not sure if this should be re-opened, or, a new ticket should be created. It appears that this function is the only thing that creates etc passwd (etc), and it's only ever called once.