- User Since
- Jul 2 2023, 10:05 PM (12 w, 5 d)
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:
PR updated for part 1/2 (vyatta-cfg-system): https://github.com/vyos/vyatta-cfg-system/pull/209
Thu, Sep 28
PR updated for part 2/2 (vyos-build): https://github.com/vyos/vyos-build/pull/427
Wed, Sep 27
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.
Tue, Sep 26
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).
Mon, Sep 25
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?
Sun, Sep 24
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.
Thu, Sep 21
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.
Wed, Sep 20
Oops, sorry about that!
PR created: https://github.com/vyos/vyos-build/pull/418
Tue, Sep 19
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
Mon, Sep 18
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.
Sun, Sep 17
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.
Sat, Sep 16
PR created: https://github.com/vyos/vyos-build/pull/414
PR created: https://github.com/vyos/vyos-build/pull/413
Fri, Sep 15
- 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.
Thu, Sep 14
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?
Wed, Sep 13
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:
Tue, Sep 12
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)):
Mon, Sep 11
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.
Sun, Sep 10
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 *
Oh sorry, I missed that this commit was for LTS 1.3.x series.
@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: