Freeradius - radacct session issue

[Alan DeKok]

On Mar 9, 2018, at 9:37 AM, Pierre Delamotte <pierre.delamotte at brightwave.co.za> wrote:
> Issue: I am picking a lot of entries in radacct that seem to have been
> updated days after session has been closed (recording of the timestamp of
> an accounting stop reception).

  FreeRADIUS only logs what it receives.  It doesn't invent accounting records.

  If a record is logged days after a session was closed, it's because the NAS sent an accounting packet days after that session was closed.

> Context: Freeradius (Version 3.0.13 see below) is deployed with a front-end
> called Radiusdesk.
> Service is provided thru WiFi APs centrally managed (Capwap) by and Access
> Controller (AC) acting as Freeradius client.
> 
> This AC is regularly performing unattended reboots, hence most likely the
> replication of Accounting Session Id.

  Ah... the NAS is broken, then.  It should NOT re-use Acct-Session-ID.  It's 2018 for crying out loud... there's just no excuse for shitty software.

> Any idea why Freeradius would overwrite an entry that has been "closed"?

  If the NAS is lying to the server and re-using Acct-Session-ID, it's difficult.  Tho FreeRADIUS adds Acct-Unique-Session-Id in order to deal with these issues.

  i.e. the default queries in v3 key off of Acct-Unique-Session-ID where possible, instead of Acct-Session-Id.

> and how we could work around that (beside ditching the AC or systematically
> moving the "closed" entries to another table upon reception of Acct_Stop)?

  The queries in v3 *should* take care of dealing with normal situations.

  But... if your NAS is broken, moving records to a different table may be a good solution.

  That, or throwing the crappy NAS in he garbage, and buying one one that works correctly.

  Alan DeKok.