On Wed, Feb 24, 2016 at 11:28:25PM +0000, Nick Lowe wrote: > The Accounting-On is useful today on receipt after an unexpected > reboot where Stops and an Accounting-Off will not have been received > to mop up all stale sessions that pertain to the NAS without having to > resort to timeouts. I certainly do not feel that it should be removed > from hostapd therefore. OK > The salient consideration and concern here should be that, today, > Accounting-On and Accounting-Off are handled by all the RADIUS servers > that use them as applying to the whole NAS. Sure, but what is "the whole NAS"? For hostapd, there is a RADIUS client (and that seems to be equivalent to "a NAS" in some texts) per BSS, so the behavior of sending out Accounting-On when a BSS comes up seems to be valid in the sense of how RADIUS is used here.. Sure, there may be RADIUS servers that have different view of what a NAS is (anything with the same IP address? anything with the same NAS-Identifier? something else?). > It is for this reason that what hostapd does today ought to change. > > There is no definition of what does or should constitute a session > identifying attribute for Accounting-On and Accounting-Off. The RADIUS > accounting RFC doesn't go here and doesn't touch on this critical > point. The original intention of the accounting RFC, clarified with > its author Carl Rigney, was that it would apply to the whole NAS. > Thus, if somebody attempts to scope/limit by adding extra attributes, > it is incompatible behaviour with nasty unexpected side effects when > these are handled as applying to the whole NAS. I don't think this discussion is going to be very fruitful before there is matching view on what "the whole NAS" is and we clearly seem to have quite different views on that. I have no issues in adding a configuration parameter to disable transmission of Accounting-On/Off per BSS (i.e., one could configure one of the BSSes to transmit these and all others not do so). I don't think I'd like to remove attributes that can identify the BSS since it would be possible for a RADIUS server to use such information. Similarly, I don't think that reference counting or some other ways of trying to automatically figure out what should work with the RADIUS server(s) is not going to work for all cases, so I see no point in even trying to add such complexity when a simple yes/no configuration parameter can be used to fine-tune this to whatever the operator believes the particular RADIUS server(s) may expect. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
