Reviewed PR #46: it is the same reorder I tested in v6 (policer-input removed from the four ip4/ip6 arcs before unbind/delete). Over ~2000 sessions with ~1 Gbit/s policed traffic, 13 resets, 6 CoA rate changes under traffic, Disconnect and reset-all, VPP did not crash (NRestarts 0). Note: the second restart on 10-22 at 14:41:14 UTC was also SIGSEGV in policer_input_node_fn_hsw (not NAT), so both 10-22 crashes match T9502. Happy to run more churn rounds on the merged build.

Sure, feel free to quote my v6 results in the T9502 PR. Thanks for picking
up the idle-timeout cause as a separate fix.

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

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.

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

I will do the test and let you know

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.

Ok I will test these today. And will share all my findings with you

I do understand that. I will update you today, after thorough testing Insha
Allah

I did some testing with patch. Counters started working and I started to
get usage in freeradius interim accounting updates. But I also noticed
another issue if I kick a user using reset command all users are
disconnected. Tomorrow I will share stats as well and will do some more
testing. Idle timeout and session timout I will check these as well
tomorrow

Tomorrow I will give it a try and update you.

can you share me patched iso or lates rolling release includes the PR ?

I can test

I was testing vyos as BNG for my network especially with vpp. But I faced same issue. I hope issue will be resolved soon