What makes you say that? rad_accounting() is called by radrespond()
which is called by rad_request() after it calls radrecv() to construct
the authreq structure, and radrecv doesn't go past the end of the
packet as far as I can tell. So padding is ignored, as it has to be since
attempting to interpret random bytes is unlikely to be useful.
To clear up some misstatements in this thread, RADIUS 2.0 is (as far as
I know) fully compliant with RADIUS Draft 5 (the Proposed Standard) and
RADIUS Acccounting Draft 5, except that it only supports 16-character
long passwords, not the full 128. It is not however, properly
speaking, a reference implementation, because it's only available in
source form to Livingston customers (defined as anyone who owns
Livingston hardware).
RADIUS 1.16 is still useful as a reference implementation since the
only things that have changed since it was written are dictionary
entries, accounting packet authenticators, and that users that aren't
found should generate access-rejects instead of being silently
ignored.
-- Carl Rigney cdr@livingston.com