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

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

I can still reproduce the AES-GCM issue on a newer build.

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

• https://github.com/vyos/vyos-build/pull/1270
• https://github.com/vyos/vyos-1x/pull/5410

See https://github.com/vyos/vyos-1x/pull/5409

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.

Thanks for catching this, a.kudientsov — and sorry for the regression. The mistake was narrowing the bare except: in fqdn_resolve() to except gaierror: based on the assumption that getaddrinfo() only ever raises gaierror, without checking that other OSErrors (e.g. transient network failures) can hit the same call and need to keep being
swallowed here too. c-po's fix in #5406 (back to except OSError:, since gaierror is a subclass) looks correct to me.

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

Subject fix causes firewall fqdn/domain-group regression. It narrowed fqdn_resolve() exception handling in from a bare except: statement to except gaierror:, claiming "no behavior change." That let non-gaierror OSErrors (e.g. transient network errors right after commit) escape uncaught, crashing the unguarded main loop of the vyos-domain-resolver daemon, the process that fills in D_* (domain-group) nftables sets.

Thanks for looking into this and merging the patch.

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

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

We cannot remove images after this merge

Installed images: 2026.08.14-0025-rolling
2026.08.13-0024-rolling
Cannot prompt "Do you really want to delete the image 2026.08.13-0024-rolling?" ([Y/n] default=False): stdin is not a TTY. Pass an explicit non-interactive option (e.g. no_prompt/-y) instead of relying on ask_yes_no().
Error: Process completed with exit code 1.

Reopened

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

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

We have upgraded the Strongswan to 6.x
Open a new bug report if you have similar/any issues

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

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

It is already done as part of another change.

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

@hybridops It would be great to provide both variables retaining backward compatibility. Thanks.

Thanks @sageframe for the update and the original report.

Thanks, no-prompt does the job for my case, I'll use that.

Following @rherold analysis of root cause above, cf. https://github.com/vyos/vyatta-cfg/pull/153 --- so you can simply add the no-prompt option to the script in question.

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

Related PRs:
https://github.com/vyos/vyconf/pull/64
https://github.com/vyos/vyos-1x/pull/5395

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

Thx for the Information, but I saw here also the possibility to give this to upstream finding a better solution for this.

We usually don't add docs task for the forge.
You can add PR directly to documentation repo without task number

Use the forum if you want to discuss your issue and find solutions
Phorge is the wrong place for it.

So this mean we can close the bug, because it's looks like that I need to redistrubute KERNEL ones with some filtering or you see some other option?

Root cause confirmed — this is an upstream FRR behavior change, not a VyOS bug.

Data below, but looks like different approach of FRR, could be issue there, but now I thinking how we can workaround it, just to somehow inject route into OSPFv3

Thanks for the full dump — that actually complicates things rather than confirming the kernel-FIB-metric theory. Your new output shows the static route absent from the

kernel FIB on both 1.4.4 and 1.5.1 (only proto kernel metric 256 present in each), which contradicts the earlier 1.4.4 snippet showing proto static metric 20 there. So
either that earlier capture was momentary/stale, or the kernel-installed route is not stable over time (e.g. it disappears/reappears around RA refresh or a DHCPv6 lease
event).

vyos@r0-sto.e-utp.net:~$ ip -6 r s | grep -v tun7
2001:67c:21ec::1 dev lo proto kernel metric 256 pref medium
2001:67c:21ec:9999::8 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba00::1 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba0e:100:14ab:ba50:9291:6963 dev eth0 proto kernel metric 256 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::4f7:44ff:fe8f:a860 dev eth0 proto ra metric 1024 expires 1790sec hoplimit 255 pref medium
vyos@r0-sto.e-utp.net:~$

PR https://github.com/vyos/vyos-documentation/pull/2195

Thanks - that rules out BGP/extended-nexthop entirely then, good to know it's a legitimate RA from your upstream (AWS) gateway, not a self-sent one.

Test results: rebuilt vyos-linux-firmware against the IWLMLD-enabled kernel (rolling @ 6.18.44) with the missing files included, rebuilt the ISO, and the BE200 now works end-to-end on the same hardware from the original report:

There is no BGP on that box.
This box is IPv6 client, RA are send from upstream router, in that case is AWS.

Both the config and the relevant sysctls (accept_ra/accept_ra_pinfo/
forwarding) being identical on 1.4.4 and 1.5.1 rules out an interface-
config or sysctl-default explanation. I initially suspected a kernel
patch-level difference (6.6.117 vs 6.6.144), but I don't think that's
it either: the likely real candidate is T7531 (bgpd's automatic IPv6
RA sending, the bgp ipv6-auto-ra behavior, disabled via
set protocols bgp parameters disable-ipv6-auto-ra).

vyos@r0-sto.e-utp.net:~$ uname -r
6.6.144-vyos

Thanks, that rules out a config difference - the eth0 setup (DHCP/DHCPv6/autoconf) and the resulting address are identical between the two versions.

Doesn't see difference:

---Thanks for the detailed comparison, that confirms the route-selection theory: on 1.5.1 there's now a third competing entry for this prefix that doesn't exist on

1.4.4:

How this looks like on 1.4.4, same config, for clearnes: 51.21.99.1 is this Router ID.

Follow-up: I test-built an ISO from rolling with the merged fix (e14a489) to validate on the same BE200 hardware. The initial PR works... the card is now properly detected: