With the PPPoE server on a VPP-owned interface and RADIUS returning an Idle-Timeout attribute, every subscriber session is torn down 60 s after it comes up and immediately redials. RADIUS records the disconnect as Acct-Terminate-Cause NAS-Error. Session traffic counters never move: "show pppoe-server sessions" shows 0 B / 0 B and every accounting record reports 0 bytes used, even while traffic is forwarding normally. Both symptoms have the same cause. PPPoE on the kernel dataplane is unaffected.
Steps to reproduce:
1. set vpp settings interface eth1 2. set service pppoe-server interface eth1 (+ client-ip-pool, gateway-address) 3. set service pppoe-server authentication mode radius set service pppoe-server authentication radius server <ip> key <secret> 4. Have RADIUS return Idle-Timeout = 600 in the Access-Accept 5. Connect a subscriber and watch the session
Result:
The session dies at 63 s and redials, indefinitely:
<Acct-Status-Type Stop> <Acct-Session-Time 63> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Terminate-Cause NAS-Error>
No "idle timeout" is logged, the teardown is a silent failure path. Without VPP the session runs past 180 s, no NAS-Error stops.
Root cause:
A VPP-terminated session has no kernel interface, so ses->ifindex keeps its init value -1 (session.c:80): vpphooks.c sets vpp_sw_if_index but never ses->ifindex, and ifcfg.c:103 skips the ifcfg routine for hook-owned sessions.
- ap_session_read_stats() returns -1 at session.c:420 ("if (ses->ifindex == -1) return -1;") silently, with no log line, so counters never update and radius/acct.c:59 uses the same call, hence 0 bytes in accounting.
- ap_session_timer() treats that failure as fatal (session.c:145-147): if (ap_session_read_stats(ses, NULL)) ap_session_terminate(ses, TERM_NAS_ERROR, 0); RADIUS Idle-Timeout arms this timer, which ticks every 60 s (timer.period = 60000).