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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
