It is impossible to set several addresses, but it is possible 0.0.0.0
Limits of the accel-ppp
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Apr 26 2024
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:vyos@192.168.255.11/tmp/ vyos@r4# [edit] vyos@r4# commit Archiving config... scp://192.168.255.11/tmp/ Unable to upload "scp://vyos:vyos@192.168.255.11/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'
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.
Apr 25 2024
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 ?
@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.
Possibly would make sense for CLI to fall under firewall global-options?
Allowing only ethernet interface task https://vyos.dev/T6265
After adding check, this task can be closed
Will be available in the next rolling release.
The group 224.0.0.0/24 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_timeI propose to add new option under interface
set interfaces ethernet eth1 ip[v6] base-reachable-time xxx
This sysctl option is deprecated https://man7.org/linux/man-pages/man8/sysctl.8.html
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.
Apr 24 2024
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"!
Apr 23 2024
@doctorpangloss Any updates?
@modzilla99 Could you provide an example of set commands to reproduce?