On Feb 22, 2016, at 8:57 AM, Jouni Malinen <j@xxxxx> wrote: >> 1) RADIUS accounting consumers that do not support the Event-Timestamp >> attribute but do support the Acct-Delay-Time attribute. > > Are there really such cases? If someone really cares about exact timing, > I'd recommend using Event-Timestamp. I'd be OK with either one. Realistically, systems that don't support Event-Timestamp are broken and need to die. > If this is for an intermediate accounting update, it would seem to make > more sense to just generate a completely new accounting message with > updated TX/RX statistics.. Yes. There isn't a lot of point in retrying accounting packets, when new statistics are available. Just toss the old packet, and send one with new statistics. > This sounds like undesired complexity for collecting information that is > already available from Event-Timestamp and/or Acct-Session-Time > depending on use. Event-Timestamp looks superior to this Acct-Delay-Time > mechanism and it should really be easier to modify an accounting server > (if one does not support that) than add more complex design to all NAS.. I agree. > As such, I don't really see the point of doing this without clearly > identified existing case where this needs to be done at the NAS and the > server cannot be updated to support newer design (and explanation on why > it would be possible to update NAS, but not server).. It's always easier to update the server. It's 2016. If your server doesn't support X, put a FreeRADIUS proxy VM in front of it. Don't waste everyone *else's* time by making the NAS jump through hoops to support your crappy server. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
