Dont count on it - the way things works on internet is that there are alot of people complaining at stuff but very few who does something about it :-)

If it crashes it should be reported upstream to kernel.org (and the maintainer for the r8169 driver) since VyOS is using the latest Linux Kernel LTS (current version 6.1.43 as of writing):

There is a bugzilla opened for this issue: https://bugzilla.netfilter.org/show_bug.cgi?id=1697

I can confirm that updating blacklist now is vrf aware and functional:

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

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

Added task https://vyos.dev/T5440 to fix the issue of preconfig-script doesnt show up in /config/scripts after system upgrade (add system image).

I need some help with this one.

It seems happy for now:

Note, if mgmtd is of no use in VyOS then the preferred is to have it disabled all together (after updating daemons.tmpl in case it gets enabled in future).

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

Note also that 1.4 rolling as of today (3rd aug) uses FRR 9.0 (previously I think 8.5.4 were used or something like that).

Note that you had an "s" too much in your command.

Found that the defaults in daemons-file are set by VyOS in /usr/share/vyos/templates/frr/daemons.frr.tmpl

Done!

Just to sync this task to PR 2118:

As mentioned in https://vyos.dev/T5419 the offloading should not only apply for NAT.

This particular case was resolved by adding:

I added this comment to PR 2118:

A not too uncommon workaround for this is to disable the lease-file (if possible) and give out leases based on option82 information instead.

Is this a limit of wireguard?

Then how come conntrack modules are loaded (and there is content in the ruleset "sudo nft -s list ruleset") when I have no firewall rules configured?

Tested and verified as described in the pull request:

Oh, and the reason for why using chrony instead of ntpsec is?

Why this limit?

Pull request created: https://github.com/vyos/vyos-1x/pull/2112

I can confirm that altering line 21 as suggested fixes this issue.

Out of the blue it seems like "network namespaces" would solve alot of current VRF compatability issues within VyOS:

Workaround until "system name-server" becomes vrf aware seems to be to change context into vrf INTERNET and then do a ping with VRF syntax like so:

I would vote for:

Doing some more digging it turned out that VyOS doesnt support nested routing so the gateway must be reachable (at least IP-address wise) through a physical interface - I have updated the script in the original post to adjust for that (added variable GATEWAY).

But they shouldnt take several minutes and this alone can be a reason for why not putting VyOS into production.

Out of the blue I think its a bad thing to throw stuff into the kernelmode for the fun of it.

My proposal after some testing:

I think this feature must then be modified with:

Oh ok.

I can confirm by removing the incorrect update-check url like so:

Ooh, I thought update-check should point to the iso-file like so:

Just want to jump onto the train and say that I too like the proposal of having "lo" as the main linux kernel loopback and loN as the networking loopback who is VRF-aware aswell.

I have experienced this myself several years ago where "Green Ethernet" aka "Energy-Efficient Ethernet mode" was the cause that HPE Comware switches/routers had issues with cable based Apple devices.

I think this should be configured through a config option if bash-history should be retained or not (by default it shouldnt for regular users and equal to root).

set system option keyboard-layout se-latin1

Verified in vyos-1.4-rolling-202307060317-amd64.iso but Im biased :-)

Merged with current: https://github.com/vyos/vyos-1x/commit/8afdb5ad5515a0a1ae716204f397f3d974cec714

Pull request created: https://github.com/vyos/vyos-1x/pull/2075

Actual file to modify for commit: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system-option.xml.in

Verified this particular request by modifying node.def and be able to select se-latin1.

Selectable keymaps are available in /usr/share/keymaps/i386/