- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Oct 16 2025
Oct 16 2025
hedrok moved T7803: Make failover route vrf-aware from Open to Finished on the VyOS 1.5 Circinus (1.5-stream-2025-Q3) board.
hedrok edited projects for T7803: Make failover route vrf-aware, added: VyOS 1.5 Circinus (1.5-stream-2025-Q3); removed VyOS 1.5 Circinus (1.5-stream-2025-Q4).
GitHub <noreply@github.com> committed rVYOSONEX69a9b93f71c8: Merge pull request #4794 from c-po/reuse-frr-reload-py (authored by c-po).
In PR changed interface to
It was investigated - the bug is indeed in the kernel.
Currently, the patch is proposed. But it probably would be refactored in the near future to a patch ver3:
GitHub <noreply@github.com> committed rVYOSONEXd8dc670cd3eb: Merge pull request #4781 from natali-rs1985/T7897 (authored by Viacheslav).
GitHub <noreply@github.com> committed rVYOSONEX4f46ade201e4: Merge pull request #4789 from sever-sever/T7890 (authored by Viacheslav).
Viacheslav triaged T7935: Rewrite accel-ppp-nd build to exclude whole build VPP and include VPP required dependencies as Normal priority.
Viacheslav closed T7823: DHCP-server lease cannot be cleared, a subtask of T6211: VRF support for Kea-based DHCP server, as Resolved.
Thanks for analysis and confirmation.
Confirmed fixed in v2025.10.12-0019-rolling
Oct 15 2025
Oct 15 2025
Viacheslav added a comment to T7928: load-balancing haproxy not taking into account listen-address when checking for other services on port.
There are several errors.
- listen_address instead of address
- `listen-address could has multiple values
vyos@r14# run show conf com | match haproxy
set load-balancing haproxy backend bk01 server 192.0.2.5 address '192.0.2.5'
set load-balancing haproxy backend bk01 server 192.0.2.5 port '993'
set load-balancing haproxy service wan-993 listen-address 192.0.2.2
set load-balancing haproxy service wan-993 port '993'
[edit]
vyos@r14#
[edit]
vyos@r14# set load-balancing haproxy service wan-993 listen-address 192.168.122.14
[edit]
vyos@r14# commit
[ load-balancing haproxy ]
{'backend': {'bk01': {'balance': 'round-robin',
'mode': 'http',
'server': {'192.0.2.5': {'address': '192.0.2.5',
'port': '993'}}}},
'global_parameters': {'ssl_bind_ciphers': ['ecdhe-ecdsa-aes128-gcm-sha256',
'ecdhe-rsa-aes128-gcm-sha256',
'ecdhe-ecdsa-aes256-gcm-sha384',
'ecdhe-rsa-aes256-gcm-sha384',
'ecdhe-ecdsa-chacha20-poly1305',
'ecdhe-rsa-chacha20-poly1305',
'dhe-rsa-aes128-gcm-sha256',
'dhe-rsa-aes256-gcm-sha384'],
'tls_version_min': '1.3'},
'pki': {},
'service': {'wan-993': {'listen_address': {'192.0.2.2': {},
'192.168.122.14': {}},
'mode': 'http',
'port': '993'}},
'timeout': {'check': '5', 'client': '50', 'connect': '10', 'server': '50'}}ruffy91 added a comment to T7928: load-balancing haproxy not taking into account listen-address when checking for other services on port.
tmp_address = front_config.get('address', None)shouldn't this be listen_address instead of address on line 75?
Viacheslav added a comment to T7928: load-balancing haproxy not taking into account listen-address when checking for other services on port.
Something is wrong with this check
ruffy91 added a comment to T7928: load-balancing haproxy not taking into account listen-address when checking for other services on port.
After my workaround described above:
vyos@vyos# sudo netstat -tulpn | grep 993 tcp 0 0 192.0.2.1:993 0.0.0.0:* LISTEN 513 01/haproxy tcp6 0 0 2001:0db8::25:993 :::* LISTEN 784 61/conmon
and then when configuring the other way around:
edit] vyos@vyos# set load-balancing haproxy service wan-993 port 994 [edit] vyos@vyos# commit [edit] vyos@vyos# set load-balancing haproxy service wan-993 port 993 [edit] vyos@vyos# commit [ load-balancing haproxy ] TCP port "993" is used by another service [[load-balancing haproxy]] failed Commit failed [edit] vyos@vyos# sudo netstat -tulpn | grep 993 tcp6 0 0 2001:0db8::25:993 :::* LISTEN 784 61/conmon
Viacheslav added a comment to T7928: load-balancing haproxy not taking into account listen-address when checking for other services on port.
sudo netstat -tulpn | grep 993
Viacheslav moved T7188: haproxy op-mode not reporting correct usage stats from Need Triage to Completed on the VyOS Rolling board.
vyos@r14# run show haproxy Proxy name Role Status Req rate Resp time Last change -------------------- --------- -------- ---------- ----------- ------------- web FRONTEND OPEN 4 buildin_acme_certbot BACKEND UP 0 ms 3m24s bk01 BACKEND UP 1 ms 1m8s buildin_acme_certbot localhost no check 0 ms 3m24s bk01 srv01 UP 1 ms 1m8s bk01 srv02 UP 1 ms 1m3s [edit] vyos@r14# run show ver Version: VyOS 2025.10.10-0733-integration Release train: current Release flavor: generic
The issue reproduces on 1.4.3.
This is Linux kernel issue fixed in v6.6.99 (VyOS 1.4.3 has kernel v6.6.93): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2ca1db269a8d202c3f97fd53fa7c9ef7f1bb21d6 and will be fixed in VyOS 1.4.4 with kernel update.
Till then the workaround you've found
set protocols static route6 ff00::/8 interface tun2 set protocols static route6 ff00::/8 interface tun3
should work fine - the kernel commit has message:
gre: Fix IPv6 multicast route creation.
Links from @zsdc where the problem could be
With the 1.4.7 gve driver the behaviour is the same
vyos@VyOS-for-Smoke-Tests# delete vpp
[edit]
vyos@VyOS-for-Smoke-Tests# commit
[ vpp ]
Traceback (most recent call last):
File "/usr/libexec/vyos/services/vyos-configd", line 156, in run_script
script.apply(c)
File "/usr/libexec/vyos/conf_mode/vpp.py", line 660, in apply
initialize_interface(
File "/usr/libexec/vyos/conf_mode/vpp.py", line 594, in initialize_interface
iface_new_name: str = control_host.get_eth_name(iface_config['dev_id'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/vpp/control_host.py", line 227, in get_eth_name
raise FileNotFoundError(
FileNotFoundError: A device with ID 0000:00:05.0 not found in ethernet interfacesViacheslav changed the status of T7934: Trigger rebuild linux-kernel if vyos-vpp-patches changed from Open to In progress.
natali-rs1985 changed the status of T7690: VPP add new interface to sFlow fails from Open to In progress.
natali-rs1985 changed the status of T7690: VPP add new interface to sFlow fails, a subtask of T7070: VPP related bugs the root task, from Open to In progress.
natali-rs1985 changed the status of T7691: VPP delete sFlow configuration does not work, a subtask of T7070: VPP related bugs the root task, from Open to In progress.
natali-rs1985 changed the status of T7691: VPP delete sFlow configuration does not work from Open to In progress.
I have found another implementation if someone wants to play with it https://git.ipng.ch/ipng/govpp-snmp-agentx
GitHub <noreply@github.com> committed rVYOSONEX7c021181e0bc: Merge pull request #4780 from natali-rs1985/T7750 (authored by Viacheslav).
Oct 14 2025
Oct 14 2025
@pr0ton11, do you see the same log? Can you try the latest rolling?
GitHub <noreply@github.com> committed rVYOSONEX3c4c1275493e: Merge pull request #4786 from mzpqnxow/T7723 (authored by dmbaturin).
GitHub <noreply@github.com> committed rVYOSONEX8a163d92b7de: Merge pull request #4790 from c-po/certbot-auto-renew (authored by dmbaturin).
natali-rs1985 changed the status of T7929: VPP: Too Strict Validation for NAT44 Static Rules from Open to In progress.
natali-rs1985 changed the status of T7929: VPP: Too Strict Validation for NAT44 Static Rules, a subtask of T7070: VPP related bugs the root task, from Open to In progress.
natali-rs1985 changed the status of T7930: VPP: Changing NAT44 Settings Resets `forwarding_enabled` to False from Open to In progress.
natali-rs1985 changed the status of T7930: VPP: Changing NAT44 Settings Resets `forwarding_enabled` to False, a subtask of T7070: VPP related bugs the root task, from Open to In progress.
natali-rs1985 triaged T7930: VPP: Changing NAT44 Settings Resets `forwarding_enabled` to False as Normal priority.
Yes got the information that the other side is no vyos (sorry didn't expect this) it's an current sophos box with strongswan.
It try to replicate it here between two vyos boxes the next days
Viacheslav raised the priority of T7932: Changes in the repo vyos-vpp-patches have to trigger rebuild linux-kernel instead of vpp from Low to Normal.
Viacheslav added a parent task for T7911: Wireguard support in VPP: T7221: VPP related features the root task.
Viacheslav added a subtask for T7221: VPP related features the root task: T7911: Wireguard support in VPP.
Viacheslav moved T7864: Bump HostAP version to 2.11 from Need Triage to Completed on the VyOS Rolling board.
Viacheslav moved T7864: Bump HostAP version to 2.11 from Backlog to Finished on the VyOS 1.4 Sagitta (1.4.4) board.
Viacheslav moved T7864: Bump HostAP version to 2.11 from Open to Finished on the VyOS 1.5 Circinus (1.5-stream-2025-Q3) board.
Viacheslav moved T7873: Bump Suricata version to 7.0.10 from Need Triage to Completed on the VyOS Rolling board.
@rherold any updates?
The current patch level of cURL package already contains almost all fixes (security patched: 7.88.1-10+deb12u14). We can leave the current version of cURL package.
The Suricata package has been updated to 7.0.10.
The HostAP package has been updated to 2.11.
GitHub <noreply@github.com> committed rVYOSONEX749954d75321: Merge pull request #4793 from sarthurdev/T7882 (authored by Viacheslav).
natali-rs1985 closed T7920: VPP: dataplane capacity warning is not displayed, a subtask of T7070: VPP related bugs the root task, as Resolved.
natali-rs1985 moved T7920: VPP: dataplane capacity warning is not displayed from Need Triage to Completed on the VyOS Rolling board.
Oct 13 2025
Oct 13 2025
martb@rauter# set interfaces pppoe pppoe0 address 'dhcpv6' [edit] martb@rauter# comp [interfaces pppoe pppoe0] + address "dhcpv6"