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

The blog over at claims:

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

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

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

Also adding these lines as to "completely ignore conntrack for all traffic" doesnt seem to help:

Merged, will show up in nightly 2023-10-04.

Merged, will show up in nightly 2023-10-04.

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

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 Debian package "binutils" to make "strip" work within the chroot of livebuild.

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.

Ehm, that hint already exists at line 2 of that file?

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: