In T4001#173519, @Viacheslav wrote:

Needs to re-check for 1.4/1.5

With nightly 2025.09.01-0023-rolling it is working (maybe the last kernel bump fixed it ?) :

I retriggered build
Both packages in the repo
https://packages.vyos.net/repositories/current/pool/main/r/radvd/

I did the same tests before updating this task, and it seemed like the code and build steps were fine.

Well, I'm stumped. Just to be sure the radvd developers didn't forget to change the string in the v2.20 version output, I tried manually compiling radvd v2.20 on a test Debian VM:

Hi @opswill, that is very strange. I'm not too familiar with the VyOS build process as far as dependencies go, but I'll look into it.

Has anyone tested this?

https://github.com/vyos/vyos-1x/pull/4420

MITRE has assigned CVE-2025-30095.

Did you have a chance to testing ?

Looks like it was assigned too restrictively before.

Hi there,

Is there anyone else we should tag on this ticket?

@daniel.arconada can you check this? The latest rolling has these modules.

vyos@vpp-left:~$ zcat /proc/config.gz | grep -i vdpa
CONFIG_VIRTIO_VDPA=m
CONFIG_VDPA=m
# CONFIG_VDPA_USER is not set
# CONFIG_MLX5_VDPA_NET is not set
# CONFIG_MLX5_VDPA_STEERING_DEBUG is not set
# CONFIG_VP_VDPA is not set
# CONFIG_ALIBABA_ENI_VDPA is not set
# CONFIG_SNET_VDPA is not set
CONFIG_VHOST_VDPA=m
vyos@vpp-left:~$ 
vyos@vpp-left:~$ show ver
Version:          VyOS 1.5-rolling-202503020018

@Viacheslav Yes, I will test it once it is included in the next rolling release.

@daniel.arconada are you able to test it with the next rolling release? Those options will be included.

@daniel.arconada are you able to test it with the next rolling release? Those options will be included.

PR https://github.com/vyos/vyos-build/pull/916

Both kernel and user-space support are needed. On the kernel side, you must enable vDPA-related options (e.g., CONFIG_VDPA and/or CONFIG_VHOST_VDPA) to provide the necessary infrastructure. On the user-space side, binaries that interact with VirtIO devices must be updated to take advantage of this support. For example, QEMU needs to be built with vDPA support so that virtual machines can offload packet processing to the hardware accelerator. Additionally, tools like libvirt or other management utilities might require adjustments to properly configure and utilize vDPA-enabled devices.

Is there any kernel option that should be enabled, or just some binaries or both of them?

I’d expect the behavior is correct now. There shouldn't be empty nodes. As some of them uses “default values” and system can see it as partly configured,
In any case the check is here https://github.com/vyos/vyos-1x/blob/ec18cc393591052fd1f021c4a62220ab2e537a2e/src/conf_mode/service_ntp.py#L68

FTR --ncp-disable was only supposed to disable the cipher negotiation. It was not meant to disable encryption entirely. --data-ciphers none is the way to go, but it seems you've already figure this out.

@n.fort what is the status of this?

also save information about the temporary package version: https://github.com/vyos/vyos-build/pull/820#event-14849025089

@marekm: Bugfixes will be towards current (aka 1.5-rolling as of writing) which then is being cherrypicked and backported by VyOS Networks to whatever older releases that needs that and are compatible with the change/fix/added feature.

That looks like a very much breaking change to me, not perfectly compatible. No more access to source code for LTS branches means it may not be possible to work on bug fixes (not just new functionality) anymore. So, to submit three PRs with bug fixes in the LTS branch to qualify for a subscription, one first needs to have a subscription. I don't think this will encourage more contributors to help the project. Is this intentional?