@c-po @zsdc can we consider this task as done or not yet?

configure
set interface eth0 address '192.0.2.1/24'
for vid in $(seq 1 1000); do set interfaces ethernet eth0 vif $vid address 10.$((vid/256)).$((vid%256)).1/24; done
time commit

We reviewed this issue and are planning to submit a documentation pull request for it this afternoon.

Just some new learnings

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

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

I stumbled across the same issue and as far as i could debug it, its due to usb/hid devices being outosuspended by the current vyos kernel/config.

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

Hi @hybridops could you add a PR and maintainers will take a look on proposed fix.
Thanks

I checked the current public vyos-cloud-init branches and the issue still appears to be present: cloudinit/stages.py calls util.del_file(self.paths.instance_link), while util.del_file() uses os.unlink(), so a stale real directory at that path still raises IsADirectoryError.

For clarification.
I have created a lab

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

Added repo to build VyOS custom shim-signed Debian package from repo https://github.com/vyos/shim-signed/ with our own signed SHIM.

@Viacheslav I have double checked and the issue is happening in 1.5

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

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

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

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

Good to know 1.3.8 is not affected, so having been denied access to later versions saved me from this vulnerability - thanks @syncer !
BTW, please also check out Dirty Frag while you're at it, no CVE yet. Mitigation (disallow loading of modules: esp4, esp6, rxrpc) breaks ipsec.

The OOT drivers included in 1.5 causes Kernel Panics causing the router to crash.
Removing the NIC cards (Intel ixgbe) form the system resolves the problem.

That's as I thought so that's fine.

@SteveP no. This would require us to give you HSM access for signing modules, which is not possible.

Re "Kernel: T861: add custom VyOS CA to Kernel builds for later module signing". Does this enable me to sign my Realtek .deb package? At the moment I have to create a custom kernel with CONFIG_MODULE_SIG_FORCE disabled for it to load.

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

Versions up to v1.3.8 are not affected. However, from v1.4.x onwards, including v1.5.0 and Rolling releases, all versions are affected.

Probably related:

Thanks for checking that. To get help resolving this under the LTS image I would recommend putting in a support ticket.

is needed something else to merge this?

I have tested all three current branches, and here are my findings:

https://github.com/vyos/vyos-build/pull/1171

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

Have you tested this behaviour in rolling as well?

In "static-mapping", mac-address is just "mac" in v1.5.0. Check the syntax: DHCP Server. Delete empty nodes.

Hi! Could you share your DHCP configuration and the generated file? Please provide the output of

show configuration commands | strip-private | match dhcp

and the content of

I have performed a final set of aggressive tests to rule out any network or mask calculation issues. The results confirm a deep-seated logic error in Kea's unicast handling on VyOS 1.5.0.

Will be available in the next release.