Note that command = command.lstrip() for def cmd in python/vyos/utils/process.py was reverted yesterday.

I have created a PR upstream which hopefully resolves why the logging didnt work as expected in VyOS (since the binary_rootfs in vyos-live-build isnt used by the nightly build who uses vyos-build and the deb-package of live-build from Debian 12.x (bookworm)):

Checked with #netfilter irc-channel.

I was thinking about N/D and personally I would prefer "None" to be listed for the various "show firewall" commands instead of N/D.

Resolved by: https://vyos.dev/T5564

This can be put to resolved when the backports are confirmed aswell.

Confirmed working with VyOS 1.5-rolling-202309110651

Im a bit allergic to have stuff automatically created which clearly is not enabled by the config.

I dont know if its related to this task but I noticed recently that even if I have no IPv6 configured on any interface and have IPv6 disabled for forwarding:

set system ipv6 disable-forwarding

I can in VyOS 1.5-rolling-202309080021 see an additional pim6reg interface!?

vyos@vyos:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master MGMT state UP group default qlen 1000
...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
6: pim6reg@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
    link/pimreg 
7: INTERNET: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...
8: MGMT: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...

Its also visible when running:

monitor bandwidth interface *

Latest run https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6138721359/job/16655876943

Oh sorry, I missed that this commit was for LTS 1.3.x series.

Fix by @sever regarding those failing conntrack smoketest: https://github.com/vyos/vyos-1x/pull/2234

@vfreex the referenced netfilter patch is from 2015, is that really valid for current version thats included in the Linux 6.1 LTS kernel?

The failed smoketest test_interfaces_ethernet.py can be seen at:

The failed smoketest test_protocols_pim6.py seems to have been taken care of by:

Regarding the failing smoketest test_system_conntrack.py (test_conntrack_ignore):

Something is broken in smoketest test_protocols_pim6.py:

Still errors in:

Related: https://vyos.dev/T5513

Related: https://vyos.dev/T5311

PR created (fixes https://github.com/vyos/vyos-build/commit/a863fe0): https://github.com/vyos/vyos-build/pull/395

For the tests above, which configs are actually being used?

Some observations:

Using VyOS 1.4-rolling-202309070021.

Related to https://vyos.dev/T5514 ?

Could please the vyos_debconfig files be updated aswell?

PR392 was merged in VyOS 1.4-rolling-202309070021.

In case there are other just like me who didnt know about "action continue":

Something else to consider is to increase the readcache of squashfs by changing this:

Looking at the kernel configs from both arm and x86 arch:

So what needs to be done is to copy that block and make a separate question regarding:

According to https://github.com/vyos/vyos-1x/blob/current/src/init/vyos-router it should be named:

There is a similar case going on at the forum with different workarounds which might help?

I think that would be a bad idea comparing to other vendors where you can select if you want to do IPv4 routing and/or IPv6 routing. If both are disabled the device will only do switching/bridging.

Ehm, are you sure you operate on the correct config?

Well in that case it boils down to if the FRR/vrrpd supports namespaces, various tracking (interface etc) aswell as multicast vs unicast which keepalived seems to support them all.

One can enable snmp module through:

I will put this as resolved under protest :-)

I dont know if something would break to run migrate from within another VyOS version but you could test something like this, preferly from last version that worked without errors ("5: 1.4-rolling-202306030305"?):

What VyOS version did you have there?

Note that regarding qdisc it seems that qdisc=fq_codel is nowadays supported according to:

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Using the config you provided in Slack I managed to trace the error (or I think so):

I dont agree this is resolved.

Memtest86+ can easily be included in the iso by altering the lb_config_tmpl variable in https://github.com/vyos/vyos-build/blob/current/scripts/build-vyos-image

I think VyOS might need to accept as default traffic to/from localhost towards itself for both IPv4 and IPv6.

Might be related:

Disabling all validators for both vyatta-cfg and vyatta-op bring the boot time down to approx 73 seconds.

Modifying node.def (comment out "syntax:expression:") recursively in the paths of:

Moving along in the blamegame I will after a tip try to disable the various validators being runned.

Any updates to this?

Can be related: https://vyos.dev/T2431

Continued debugging by also modifying /usr/libexec/vyos/services/vyos-configd by adding:

Attempted some debugging on this issue.

According to https://man7.org/linux/man-pages/man7/capabilities.7.html this capability can load, unload AND delete kernel modules.

Still occurs for:

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

Verified working with VyOS 1.4-rolling-202309030023.

Was missing quotes around the variable within lb_config_tmpl like so:

Some further testing:

Reference to https://jonathancarter.org/2015/04/06/squashfs-performance-testing/ using 1M blocksize will give approx the same readspeed as with default 128k blocksize but result in an even smaller file.

Regarding filesystem.squashfs the changes through changed mksquashfs syntax are:

Was missing quotes around the variable within lb_config_tmpl like so:

The firewall refactoring released 4th aug 2023 only (so far) took care about the documentation in the configuration section:

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

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

PR389 build failed:

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

There was a similar case where it turned out that INPUT/OUTPUT chains for the firewall must be updated to include the stuff VRRP is doing.

Reported in: https://forum.vyos.io/t/error-show-dhcp-lease/12030

See this task instead: https://vyos.dev/T5536

1. Error in show firewall group:

I can confirm that I experienced the same thing with update to VyOS 1.4-rolling-202308310021.

I assume backports will be used once VyOS 1.3.4 gets compiled?

PR1 didnt seem to have any affect on this night build:

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

Can be resolved by route-map acting on community (for example <ASN>:888) and setting nexthop to 192.0.2.1 (optional tag 666) or for IPv6 set nexthop 0100:: along with a static route where 192.0.2.1/32 and 0100::/64 have null0 as nexthop.

Some tests on filesystem.squashfs from VyOS 1.4-rolling-202308280021.

A note from https://forum.vyos.io/t/clear-logs-on-vyos/6878/10?u=viacheslav that there might be issues if removing directories from within / var/log/* doesnt occur to PR381 since that PR was specific about which files and directories to remove when it comes to / var/log. That is only files NOT directories were removed from / var/log.

A baseline could be to look at the linux kernel config used by Alpine Linux for their RPI-builds:

Just a comment: