Summary
ap_session_timer() ended a session that reached its idle timeout with TERM_SESSION_TIMEOUT. TERM_IDLE_TIMEOUT exists in ap_session.h and radius/acct.c maps it to Acct-Terminate-Cause = Idle-Timeout, but nothing used it. So the accounting stop of an idle session said Session-Timeout, and the RADIUS server could not tell an idle session from one that reached its session timeout.
This uses TERM_IDLE_TIMEOUT for the idle check. The session timeout check right below, and the Session-Timeout handling in radius/radius.c, keep TERM_SESSION_TIMEOUT. One line.
It was found by a tester of the VPP PPPoE server, who saw Idle-Timeout 120 fire with Acct-Terminate-Cause Session-Timeout while no Session-Timeout attribute had been sent.
Test
Tested on a VM with VPP 25.10 (VPP-terminated sessions) and with a kernel-mode PPPoE server (kernel ppp interface, server and client over a veth pair on the same VM). A RADIUS server answered with Idle-Timeout 30, the client sent no LCP echo and no traffic:
| before | after | |
|---|---|---|
| VPP session | ends after 120 s, Acct-Terminate-Cause 5 (Session-Timeout) | ends after 120 s, Acct-Terminate-Cause 4 (Idle-Timeout) |
| kernel session | ends after 123 s, Acct-Terminate-Cause 5 (Session-Timeout) | ends after 120 s, Acct-Terminate-Cause 4 (Idle-Timeout) |
The VPP numbers come from the current VPP PPPoE branch built with and without this change. The kernel numbers are from the unmodified binary of the image and from a build with this change.
The 120 s are two ticks of the 60 s session timer. The first tick sees the counters that changed while the session was set up, so the idle time only counts from there. That is existing behaviour and not changed here.