@saadinnocent909 if NAT44 together with PPPoE crashes again on a build with the current fixes, this is what I need, in this order:

saadinnocent909 thank you, and thanks for the permission: the T9502 pull request (https://github.com/accel-ppp/accel-ppp-ng/pull/46) quotes your v6 results and your comment on T9502 about the second crash.

Quick heads-up: I’ll be attending an event next week (RIPE93 in Sofia) , but I’ll still be working on the tickets as usual, so no worries about any major delays.
On a side note, I’ve been really enjoying our exchanges and would love to learn a bit more about your specific use case outside of this ticket system whenever you have some free time.
If you’re open to a quick off-topic chat, feel free to reach out to me via email at (ruben at insecure . pw)

The fix is open as a pull request: https://github.com/accel-ppp/accel-ppp-ng/pull/45

The change is open as a pull request: https://github.com/accel-ppp/accel-ppp-ng/pull/46

PR: https://github.com/accel-ppp/accel-ppp-ng/pull/45

@saadinnocent909 thank you, this is the most useful test so far: a full day with about 2,000 sessions, the exact comparison of the accounting stop with show interface, and the details on the resets.

@Viacheslav thanks. I do not think the RFC decides this, so let me explain what I mean.

@saadinnocent909 sorry for the confusion with the last build. I described v5 as "v3 plus the review changes", but it was built on a newer accel-ppp-ng base than v3, and I left out the policer change from v4, which is the one you are testing for the SIGBUS. Please use v6 and ignore v5.

@saadinnocent909 there is a new test build, v5: https://cloud.insecure.pw/s/695B3YeXyZWpHn6

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

@saadinnocent909 (a mention subscribes you to this task) for your answers about crashes see https://vyos.dev/T9211, where I ask about the backtrace, the NAT44 output-feature workaround and the policer. The crash of T9501 (NAT44, nat_pre_in2out_output) is a different one from the crash of this task (policer_input_node_fn_hsw). T9211 reports a second VPP restart (14:41:22 UTC) without a cause, which could be either of them. The hook that creates and deletes the session interface is where the policer features are removed here and where marking each pppoe_sessionN as NAT inside (option 1 of T9501) would go, so if that is done the removal has to be the reverse of the setup from the start.

@saadinnocent909 a question for your crash tests, so that the VPP crashes are not mixed up. There are at least two different ones now:

Test result so far: on a VM with three sessions with a RADIUS rate limit (VPP policers in use) and a ping flood on each, ending all sessions and reconnecting 15 times, VPP did not crash with the old order and not with the new order, and no policer was left behind after any round with the new order. With three sessions the window is too small to hit, so this does not show that the new order is the fix, only that it removes the policers cleanly. A build with the change is in the task T9211 for the tester, who has the load for it.

@saadinnocent909 a fourth test build, for the policer crash (https://vyos.dev/T9502). It is the third build plus one change in libvyos_vpp.so, the other two files are the same:

@saadinnocent909 thank you for the detailed test, this is very useful. Going through your points:

New information for the decision between pdns-recursor 4.8.8 (the bridge in vyos-build #1329) and a newer series: PowerDNS published Security Advisory 2026-12 on 21 October (https://blog.powerdns.com/2026/10/21/powerdns-security-advisory-2026-12-for-powerdns-recursor, details in https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2026-12.html). Seven CVEs, fixed in 5.3.12 and 5.4.8. The advisory names up to 5.3.11 and 5.4.7 as affected and says nothing about 4.x, which is end of life and not checked.

@saadinnocent909 I could reproduce the reset problem, and it is not caused by the test build. It is a crash that is already in the current rolling image.

PR https://github.com/accel-ppp/accel-ppp-ng/pull/44
@saadinnocent909 If you want test I can give you a new package.

@saadinnocent909 thank you for testing, good to hear that the counters work now and that the usage shows up in the interim updates.

PR https://github.com/vyos/vyos-build/pull/1331 but the fix for T9493 must be merged before. I can't create teh PR in the moment cause the PR number limit.

I reproduced this and tested Kea 3.2.1 on a rolling VM (2026.10.16-0024-rolling).

@saadinnocent909 there is no ISO or rolling image with the fix, the PR (https://github.com/accel-ppp/accel-ppp-ng/pull/42) is still in review. Here is a test build of the three changed files that you can put on an existing rolling system:

I reproduced this on a rolling VM and have a fix. I can not open a pull request for it: GitHub limits me to 5 open pull requests in vyos/vyos-1x and all 5 are in use. The commit is on my fork, anyone can take it as it is or I open the PR as soon as a slot is free:

Two additions: how serious the open CVEs are, and a simpler way to get to 5.x through T7557.

I prepared this as a draft PR so that someone else can continue if needed: https://github.com/vyos/vyos-1x/pull/5585

I implemented option one with PR https://github.com/vyos/vyos-build/pull/1329

Summary of what I found, and a question on the direction.

@Viacheslaw I will take care. Can you assign it to me?

@saadinnocent909 can you test my PR in your environment?

Reproduced on a VM (rolling, kernel 6.18.55-vyos) with the steps from the description:

I reproduced this on a VM with rolling (PowerDNS Recursor 4.8.8, pdns-recursor 4.8.8-1+deb12u1) and the cause is in the recursor, not in vyos-hostsd or the addNTA lines. The addNTA lines only set DNSSEC negative trust anchors, they do not take part in resolving names.

@a.kudientsov thanks for the detailed report and the reproducer. You wrote that you have local patches for both parts (skipping the drain in lcp_nl_pair_add_cb when
there is no socket, and the state sync during the resync window) that remove the stuck state in your tests.

I checked this against current rolling and the description matches what I see in the sources:

Because of that the fix belongs in FRR: batch a hard clear (BGP_CLEAR_SOFT_NONE) also when a family is given. Then clearing a group with a family filter is fast as well.
FRR issue: https://github.com/FRRouting/frr/issues/23771. I also opened a patch with a topotest: https://github.com/FRRouting/frr/pull/23779.

I looked at this in the FRR source (stable/10.5 and master, same code), and the cause is a bit wider than the ip token.

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

With no traffic-selector configured, the template falls back to 0.0.0.0/0,::/0 for both local and remote. That is the same proposal as listing both families explicitly, so the result is identical: the responder narrows the CHILD_SA to IPv4 and IPv6 stays down. The default does not help, because both families are always sent in one CHILD_SA.
The only way to get both families up against this peer is one CHILD_SA per family. That is what the PR does: https://github.com/vyos/vyos-1x/pull/5565. I tested it against a real Sophos Firewall by configuring the two children by hand: both were installed and IPv6 worked, with no change on the Sophos side.

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

Thanks for the capture, that settles it.

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

Thanks for testing, @DuxOv8.

Update: in our case this was not an FRR bug, it was a firewall problem on our side.

@DuxOv8 as you could see on the PR link is it not merged yet.

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

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

PR: https://github.com/accel-ppp/accel-ppp-ng/pull/42

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

PR: https://github.com/vyos/vyos-1x/pull/5459
DOCS-PR: https://github.com/vyos/vyos-documentation/pull/2240

Dublicate with T9290

https://github.com/FRRouting/frr/pull/22921 got merged can we ask the frr project for a backport or do it self?

Implemented conditional DHCP options via client classification, extending the existing client-class framework (previously limited to Option 82 relay-agent matching):

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.

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

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

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

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

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

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).

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.

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).

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

---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:

Looking at your last output more closely - I think this might not be an FRR-side redistribution bug at all, but a route-selection conflict on your box.

Took a look at the current vpp-1.5 code to scope this out.

hi please try:

Root cause found: ask_yes_no() in python/vyos/utils/io.py:57 catches EOFError from input() but loops right back to the top of while True with no backoff or exit condition:

Thanks for the detailed follow-up, this is helpful.

PR: https://github.com/vyos/vyos-1x/pull/5389
PR: https://github.com/vyos/vyos-documentation/pull/2193

@Apachez default powerdns: https://doc.powerdns.com/recursor/security.html it seems it was taken over from the debiab powerdns package.

Hi, thanks for the detailed report.