Tested as working in: VyOS 1.5-rolling-202404250020

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

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

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

It is impossible to set several addresses, but it is possible 0.0.0.0
Limits of the accel-ppp

looks good for VyOS 1.5-rolling-202404260019 and VyOS 1.4-stable-202404120309

vyos@r4# set system config-management commit-archive location scp://vyos:[email protected]/tmp/
vyos@r4# 
[edit]
vyos@r4# commit
Archiving config...
  scp://192.168.255.11/tmp/ Unable to upload "scp://vyos:[email protected]/tmp//config.boot-r4.vyos.local.20240426_153518": [Errno 101] Network is unreachable
run-parts: /etc/commit/post-hooks.d/02vyos-commit-archive exited with return code 1
[edit]
vyos@r4#

It looks working on VyOS 1.5-rolling-202404260019

set system domain-name 'vyos.local'
set system host-name 'r4'
set system static-host-mapping host-name r4.vyos.local inet '100.64.0.14'

So if all packages needed are in fact the vyos-build/packages then this should be fairly simple to build and make your own APT repo off of.

Perhaps those changes should be within the firewall context?

Hi Giggum,
our previous solution was IPv4 only and not so nice integrated in VyOS,
therefore there are several reasons why a rework is a good idea.

In T6258#185013, @Apachez wrote:

Im thinking since sysctl can be changed after the system have completed its boot shouldnt the "system sysctl" be runned among the last tasks according to "/usr/libexec/vyos/priority.py", which would also fix this issue ?

@adestis did your previous solution account for non-IP address characters in a given blocklist? For example the https://www.spamhaus.org/drop/dropv6.txt list has a bunch of stuff that would need to be ignored.

Im thinking since sysctl can be changed after the system have completed its boot shouldnt the "system sysctl" be runned among the last tasks according to "/usr/libexec/vyos/priority.py", which would also fix this issue ?

If all of this would be done by the build script (download sources, apply patches, build binary packages and copy them to a local filesystem) there would be no problem.
I can't even see the list of packages in that 403 Forbidden repo - all of it blocked completely, not just access to binary packages.

Good.
So, all code is in github.
you need to spend bit of time and learn how to build packages and make them into repo
after you point vyos-build to that repo and good to go
it's time consuming, but once you have set it up, after it will not require that much time

@Apachez, there is no easy way to fix anything related to sysctl, until one component depends on another.
Especially, for example, if we have to deal with "dynamic" interfaces.
Globally, this task is still open and could contain subtasks.
Thanks!

In T6266#184977, @sarthurdev wrote:

Possibly would make sense for CLI to fall under firewall global-options?

Note that "base_reachable_time_ms" is still valid while "base_reachable_time" is obsolete.

OK, so where can I find the source (without the artwork) with the necessary patches and working build scripts? No problem to use my own CPU cycles and bandwidth and disk space, I can wait longer for the build to finish, sometimes (on sunny days) I even have some free electricity :) - in fact I would even prefer to build the binaries myself (of any packages not directly copied from Debian) rather than trust an external repo. And no problem, you've just got the 868th star from me, I simply didn't know this is something that matters. I have never distributed the LTS images to third parties, just using them internally. Yes, for some small scale production use (single-person business, running a very small local ISP for a few hundreds of customers) as a BGP router and PPPoE server (the latter replacing MikroTik because of their unfinished IPv6 support), not big enough to be able to afford a subscription.

Possibly would make sense for CLI to fall under firewall global-options?

When we say build from the source, we mean build from the source
see https://blog.vyos.io/community-contributors-userbase-and-lts-builds

Stay tuned; check our blog post.

Allowing only ethernet interface task https://vyos.dev/T6265
After adding check, this task can be closed

Sorry about the priority, but it may be quite serious for those who will lose access due to end of program "images from donations" on May 1, and would like to be able to build stable images from source.

Will be available in the next rolling release.

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

Unfortunately not yet resolved for 1.4 - now reported separately here https://vyos.dev/T6264

The group is reserved

r4(config)# interface eth2
r4(config-if)# ip igmp join 224.0.0.0 224.0.0.10
% Configuration failed.

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

vyos@r4# set interfaces ethernet eth2 ipv6 base-reachable-time 28
[edit]
vyos@r4# commit
[edit]
vyos@r4# 
[edit]
vyos@r4# sudo sysctl net.ipv6.neigh.eth2.base_reachable_time_ms
net.ipv6.neigh.eth2.base_reachable_time_ms = 28000
[edit]
vyos@r4# 
vyos@r4# cat /proc/sys/net/ipv6/neigh/eth2/base_reachable_time_ms 
28000
[edit]
vyos@r4#

In T6258#184876, @canoziia wrote:

In T6258#184875, @Viacheslav wrote:

This sysctl option is deprecated

DEPRECATED PARAMETERS         top

       The base_reachable_time and retrans_time are deprecated.  The
       sysctl command does not allow changing values of these
       parameters.  Users who insist to use deprecated kernel interfaces
       should push values to /proc file system by other means.  For
       example:

       echo 256 > /proc/sys/net/ipv6/neigh/eth0/base_reachable_time

I propose to add new option under interface

set interfaces ethernet eth1 ip[v6] base-reachable-time xxx

This sysctl option is deprecated

DEPRECATED PARAMETERS         top

Hi everyone, I think I found the simplest configuration that can reproduce this problem. If we set up firewall and use this command(set system sysctl parameter net.ipv6.neigh.eth3/2) in configuration at the same time, an error message will show when startup.
This is an example

set firewall
set interfaces ethernet eth0 address 'xxx.xxx.184.32/24'
set interfaces ethernet eth0 hw-id 'xx:xx:xx:xx:xx:50'
set interfaces ethernet eth1 hw-id 'xx:xx:xx:xx:xx:ba'
set interfaces ethernet eth1 vif 2
set interfaces loopback lo
set protocols static route xxx.xxx.0.0/0 next-hop xxx.xxx.184.1
set service ntp allow-client xxxxxx 'xxx.xxx.0.0/0'
set service ntp allow-client xxxxxx '::/0'
set service ntp server xxxxx.tld
set service ntp server xxxxx.tld
set service ntp server xxxxx.tld
set service ssh
set system config-management commit-revisions '100'
set system conntrack modules ftp
set system conntrack modules h323
set system conntrack modules nfs
set system conntrack modules pptp
set system conntrack modules sip
set system conntrack modules sqlnet
set system conntrack modules tftp
set system console device ttyS0 speed '115200'
set system host-name xxxxxx
set system login user xxxxxx authentication encrypted-password xxxxxx
set system sysctl parameter net.ipv6.neigh.eth1/2.base_reachable_time_ms value '14400000'
set system syslog global facility all level 'info'
set system syslog global facility local7 level 'debug'

If delete the first line (set firewall), system will start normally without error message.

Meanwhile, trying to build 1.4 fails for a different reason - Debian 12 (bookworm) is still where it was, but sagitta-packages.vyos.net gives a 403 error:

So most likely we will have to find another implementation.

I sent a question to ISC regarding https://www.isc.org/blogs/dhcp-client-relay-eom/ and:

Reopen to investigate.

I tested in the latest rolling version and the traceback error is not received anymore and the tunnel ip column shows n/a but with multiple entries.
It still shows the disconnected client and I assume it should not show disconnected clients

Close it as wontfix due to legacy backend.

In some cases, we can't predict the interface name (if the interface name is over 15 characters) https://vyos.dev/T6222

@sempervictus Any updates or additional context?

Fixed, VyOS 1.5-rolling-202404240023

vyos@r4# run show conf com | match "bri|tun0"
set interfaces bridge br0 member interface tun0
set interfaces tunnel tun0 encapsulation 'gretap'
set interfaces tunnel tun0 remote '192.168.122.111'
set interfaces tunnel tun0 source-address '192.168.122.14'
[edit]
vyos@r4# delete interfaces tunnel 
[edit]
vyos@r4# commit
[ interfaces tunnel tun0 ]
Interface "tun0" cannot be deleted as it is a member of bridge "br0"!

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