On Mon, Feb 22, 2016 at 04:57:38PM +0000, Nick Lowe wrote: > 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. 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.. On Mon, Feb 22, 2016 at 05:09:21PM +0000, Nick Lowe wrote: > I would be happy with this but still consider adding the > Acct-Delay-Time in to all Accounting-Request packets a much better > solution than refusing to bring service up / or taking it down. > It seems drastic, especially as many routers/APs frequently fail to > complete NTP time sync for some reason. As the RADIUS protocol gives > up a better pallet of options here, we should make use of it, in my > opinion. In theory, I agree. That said, I really want to get a clear confirmation that this is a real world issue and not just theoretical protocol discussion before spending time to work on implementing support for Acct-Delay-Time (and commit to maintaining such functionality). 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? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
