Acct-Delay-Time missing with RADIUS accounting

Nick Lowe nick.lowe at lugatech.com
Mon Feb 22 08:57:38 PST 2016


Think of this scenario:

Accounting-On sent, not received by accounting server, no ack received
by RADIUS client therefore - queued to be resent.
Client associates to a BSS, Start sent, received by accounting server,
ack received by RADIUS client.
Accounting-On resent, received by accounting server, ack received by
RADIUS client.

The RADIUS accounting server then considers the session stale / dead.

Cheers,

Nick

On Mon, Feb 22, 2016 at 4:47 PM, Jouni Malinen <j at w1.fi> wrote:
> On Mon, Feb 22, 2016 at 03:26:51PM +0000, Nick Lowe wrote:
>> But that leaves you with a reliability issue where you get resends of
>> an Accounting-On, Accounting-Off, Start, Stop... you don't know when
>> the original event actually occurred.
>
> What's the use case for being so careful about Accounting-On and
> Accounting-Off? I understand wanting to get more accurate
> Accounting-Start/Stop, but those already include the Event-Timestamp and
> Acct-Session-Time attributes where the former gives you calendar time
> from NAS and the latter gives you the real duration of the session in
> seconds based on monotonic time on the NAS.
>
> If there is a critical requirement of getting the correct calendar time
> the session happened, I'd assume starting hostapd only after having
> confirmed that NTP has synchronized the time would be acceptable (and if
> necessary, stopping hostapd if time sync is somehow lost).
>
> This is also talking about the case of having to retransmit accounting
> messages which has a limit on how many times (and for how long) that is
> done. As such, even in the worst case, the difference is limited to
> couple of minutes and if someone needs to get more detailed information
> on a specific session afterwards, it's likely to be able to get pretty
> good estimate on the time based Event-Timestamp and RADIUS server
> receive timestamp over number of frames from the same NAS..
>
> In other words, I'm still missing a detailed description of a real world
> use case that would justify the extra complexity on NAS on top of what's
> already available in hostapd.
>
> --
> Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list