> I understand that this type of sequence can be seen on a RADIUS server, > but I'm not that interested in theoretical discussion in this front > unless a real world case can be identified. > > I don't see how one would implement a RADIUS server to do something like > this.. Are Accounting On/Off really used to override Accounting > Start/Stop information on a session? Is this a case for a deployed > server today? I would have assumed the sessions would be kept separate > and On/Off messages more or less ignored for any practical purpose.. Easily! Yes, the Accounting-On notifies the server that service has become available, and, as a logical consequence any sessions it considers existing for the NAS are stale. FreeRADIUS and Radiator can do this. The Accounting-Off cannot be relied upon as you commonly may not get this - think of NAS losing power, rebooting unexpectedly etc. Some NASes don't send it. The purpose of RADIUS accounting is to acccount, we should try to make sure that it is as accurate as possible. > Can an example deployed server implementation that uses local RX time > stamp and Acct-Delay-Time instead of Event-Timestamp (or > Acct-Session-Time as far as duration of the session is concerned) be > identified? Modern RADIUS accounting consumers/servers will all support the Event-Timestamp attribute and tgey should be fixed where they don't (no disagreement here!), again the primary concern is where the Event-Timestamp cannot be populated because NTP sync hasn't completed successfully on the NAS. This is a realistic, common scenario that happens quite frequently. I don't think not offering service is reasonable when we can do better. There is also a common race observed in NASes where hostapd/its equivalent and NTP sync take place independently during startup. There, the initial Accounting-On and a few Starts will contain no Event-Timestamp. NTP sync can also have delayed completion due to other issues, or no completion at all. Nick _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
