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)

I will check this tomorrow. By the way I am that 2000 session tester

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.

Thanks @ruben-herold. I tested v6 (sha256 047910eb…4a94a5 OK) for a full day. Setup: rolling 2026.10.16-0024, VPP 25.10.0, PPPoE on VPP eth0, FreeRADIUS on a separate VM, rate-limit via Filter-Id (no vendor), 2 MikroTik CPEs + ~2,000 PPPoE load sessions. Installed 11:33 UTC. I removed my LD_LIBRARY_PATH drop-in and it starts fine, so the RUNPATH fix works. accel-pppd ran the whole test with one PID and NRestarts=0, so the EBADF abort (#44) did not come back.

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

RADIUS rate-limit silently does nothing when the vendor name has the wrong case (vendor mikrotik)

I think it is expected
What RFC says how to handle a wrong attribute if the vendor name is wrong?

I working on it. I will update you once testing is done

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

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

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

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

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

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

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

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

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

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

I will do the test and let you know

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

Thanks @ruben-herold, I tested the package accel-ppp-ng-T9211-v2 (#42 + #44).
▎
▎ Setup: fresh VyOS 2026.10.16-0024-rolling VM, VPP 25.10.0 (PPPoE on eth0, NAT44 removed for this test), FreeRADIUS 3.2.5 + PostgreSQL, MikroTik CHR clients: 2 real CPEs + up to ~1,700 PPPoE clients on macvlans. Idle-Timeout = 120 in radgroupreply for the group of the 2 CPEs only. No interim interval configured.
▎
▎ 1. Install: the binaries have no RUNPATH, accel-pppd exits with libtriton.so: cannot open shared object file (libluasupp.so also not found for libradius.so). The stock binary has RUNPATH /usr/lib64/accel-ppp. With a drop-in Environment=LD_LIBRARY_PATH=/usr/lib64/accel-ppp it starts.
▎
▎ 2. #44 works. reset pppoe-server username usman with the other sessions up: same accel-pppd PID before and after, no EBADF/ABRT in the journal. Also reset pppoe-server all with ~1,500 sessions: the daemon stayed up (NRestarts=0). On stock the first teardown aborts the daemon (backtrace triton_md_disable_handler <- destablish_ppp, same as your strace).
▎
▎ 3. Idle-Timeout (#42) — not fixed yet in my test. radacct for the CPE user usman:
▎ - stock: 7 of 9 sessions ended after exactly 60 s with Acct-Terminate-Cause = NAS-Error, all with 0 bytes.
▎ - with the package: rx bytes are counted now (e.g. 477 B), but sessions still end with NAS-Error: 4 sessions after 60 s or 120 s while VPP was up (two more ended around the VPP restart in point 5). None ended with Idle-Timeout.
▎
▎ 4. Counters drop to 0 under load. When ~1,000 sessions connected within a minute (19:37-19:38 local), the counters of the two CPE sessions went from 1.4 KiB / 477 B to 0 B, and usman ended with NAS-Error at the next timer tick (19:38:48). I think this is the heartbeat check: /sys/heartbeat in the stats segment changes about every 10 s, so the 3 s / 10 s "VPP instance lost" limits trigger while VPP is busy, the stats read returns an error and the session is ended. In my own build of dd07b23 + #42 + #44 I raised those limits to 35 s; with that, two CPE sessions stayed up 19 h with ~2,000 sessions online and the counters stayed correct.
▎
▎ 5. VPP worker crashes (not caused by #44, but #44 makes this path run).
▎ - 13:44:52 UTC, ~1,500 sessions, sessions being torn down: received signal SIGBUS in policer_input_node_fn_hsw, vpp-failure-handler restarted VPP, all sessions dropped.
▎ - 14:41:22 UTC VPP restarted again with ~1,700 sessions and no config change: [VPP 14:41].
▎
▎ My guess for the policer crash: vpppolicer_remove_limiter() first calls policer_input(apply=0) — VPP sets policer_index_by_sw_if_index to ~0 and only disables the device-input arc — then deletes the policer, and only after that disables the policer-input features on the ip4/ip6 unicast/multicast arcs (added by vyos-vpp-patches 0018). A packet in that window reads pm->policers[~0]. Disabling those four features before vpppolicer_set_input(0, ...) should close it. CoA reaches the same code through install_limiter(). Before #44 this path was never reached, because the daemon aborted first.

What are the requirements?
Will it be enough to use a single VRF, or is the VRF received via a RADIUS attribute?