PR created (for current): https://github.com/vyos/vyos-build/pull/432

Please revert that commit (remove that hook) and use the excludes-file instead.

I suppose the maintainers already considered the below but I got a suggestion on how to resolve this issue:

Created https://vyos.dev/T5622 which must first be resolved before T5593 can get successfully merged.

PR updated for part 1/2 (vyatta-cfg-system): https://github.com/vyos/vyatta-cfg-system/pull/209

PR updated for part 2/2 (vyos-build): https://github.com/vyos/vyos-build/pull/427

PR created for part 1/2 (vyatta-cfg-system): https://github.com/vyos/vyatta-cfg-system/pull/209

Build was successful and smoketests are currently in progress.

If build and smoketests are successful a commit will arrive later today.

Point 1 might be solved by using a hooks/live-script for the binary part which is the part after the chroot have been created.

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

Turned out to be little of a challenge do "just" strip all binaries (and libraries, modules etc).

Have to add "binutils-common" to make "strip" work within the dockerimage.

Implement hooks-script for livebuild that recursively go through following directories using "strip --strip-all" (syntax to be verified):

Shouldnt that be default for lb then in the vyos buildscripts and how does --debug affect things other than logging during build?

What is the "system update-check url" supposed to be once its implemented?

Verified to be working as expected.

@jestabro I havent verified it yet but then perhaps the buildscript for VyOS should be altered to include --verbose?

Verified through smoketests.

Verified through smoketests.

The quickfix is to add a space for your paths so something that looks like /usr/local/bin if cloudflare blocks that you just add a space after the first / and the WAF is bypassed.

Oops, sorry about that!

In T5601#160566, @vvinci00 wrote:

Hello,

I need to reverse proxy TCP traffic.
the traffic is not HTTP/HTTPS

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

Some highly unscientific tests (only did 3 reboots of each to rule out that any uncached data at the host would affect the result since I run this in a VM through VirtualBox 7.0) shows a difference of up to 2.1% improvment when having a config with 200 static routes.

Perhaps a possible way to detect if the nic supports hardware flowtables or not.

Some feedback from the #netfilter channel over at libera.chat:

I got some funny results which I hope somebody else (with a faster cpu) are able to verify?

Im guessing that what this task complains about has a huge part of the time it takes to complete smoketests.

PR updated (again): https://github.com/vyos/vyos-1x/pull/2280

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

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

I will put this as "wontfix" because a fix would need additional work of stopping/starting correct FRR-service (if this occurs in future then this task can be reopened).

I will close this task as a duplicate of https://vyos.dev/T4502 where work is in progress.

Using VyOS 1.5-rolling-202309170024.

So what remains is how to solve point 1.

It looks like point 3 can be taken care of:

Ok, I was thinking if that then waited for some password or such.

How does a simple "sudo bash" work?

Testing point 2 above with VyOS 1.5-rolling-202309170024.

This is the one I was thinking of:

This seems to have been resolved since a few days (1.5-rolling nightly).

Output of ps auxww | grep -i frr after proposed v3 is applied:

Update of proposed changes (Ill call them proposed v3).

Update of proposed changes (Ill call them proposed v2).

I can create a PR if everyone agrees upon the proposed changes above however I have limited capability to test each and everyone of these changes.

Proposed data/templates/frr/daemons.frr.tmpl:

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

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

1. Using hardware flowtable (flags offload;) on an interface which doesnt support it returns an error:

Tried to enable both software and hardware flowtable with VyOS 1.5-rolling-202309151051:

How does FRR/vrrpd work regarding SNMP compatability?

Note that PR2062 is broken.

Regarding testing of arm-builds, hopefully this article might come handy (how to use qemu-system-aarch64 (on x86) part of the qemu-system-arm package):

The excludes-file in PR406 had incorrectly a '/' as first character (for the directory to be excluded from the squashfs-file).

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

Should probably add "-M rpki" permanently to FRR/bgp.

Could the error from latest nightly be due to that rpki module isnt loaded for FRR/bgp?

Could https://vyos.dev/T2044 be related to the failed nightly build from last night?

This is still the case in VyOS 1.5-rolling-202309130022:

Suggestion of "hidden" ruleset (visible when doing show firewall and show firewall statistics):

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

Found out that mksquashfs supports -ef EXCLUDE_FILE as a file that (line by line) defines which files and directories to be excluded during creation of filesystem.squashfs. Adding -wildcard will make it possible to use wildcards within the EXCLUDE_FILE.

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

Something like this console command but more handy in op-mode?

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

Turns out that the values who override the vyos-config values are set in /etc/sysctl.d/30-vyos-router.conf:

I can confirm that setting these values AFTER boot (and doing commit) they will be properly set.

Turns out to exist an RFC for this regarding IPv6 along with a naming:

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: