On Wed, Feb 24, 2016 at 09:22:29PM +0000, Nick Lowe wrote: > hostapd is currently acting contrary to the original intent of RFC > 2866 as it is sending Accounting-On and Accounting-Off > Accounting-Request packets on a per-BSS basis and not on a per-NAS > basis when accounting_init() is called from hostapd_setup_bss() and > accounting_deinit() is called from hostapd_free_hapd_data(). > > I filed an errata against the RADIUS accounting RFC last year around > APs that exhibit this behaviour as the original intent of the RFC was > ambiguous. How would the hostapd behavior be contrary to the original intent if the original intent is ambiguous? In any case, whatever the original intent may have been, it does not look like this really could have covered all the cases that have shown up over the years with virtual interfaces, supporting multiple networks in a single device, etc. Please keep in mind that each BSS in hostapd has its own instance of a RADIUS client. Each BSS can have different RADIUS server configuration and just like a BSS is a virtual concept, a NAS could be similarly virtual with NAS-per-BSS mapping being a possible interpretation. Each BSS ("virtual NAS"?) can also use a different NAS-Identifier and even a different IP address (both NAS-IP-Address and the source IP address of the RADIUS message). As far as the current hostapd design is concerned, there is a very clear NAS-to-BSS mapping, i.e., each BSS has its own instance of a NAS/RADIUS client with completely independent configuration for both the local identity (NAS-Identifier) and RADIUS server. > See: https://www.rfc-editor.org/errata_search.php?rfc=2866&eid=4485 > To solve this, I would suggest reference counting against RADIUS > servers, sending Accounting-On as the first BSS comes up and > Accounting-Off as the last BSS goes down. This must be tracked on a > per-RADIUS server basis to be done correctly. Wouldn't it be simpler to just stop sending Accounting-On and Accounting-Off messages completely if they can cause issues for RADIUS servers? The more I hear about the issues with those (like the earlier discussion on races with Start/Stop and retransmissions), the less I see how these would work in practice to get any good outcome. hostapd is sending out Start/Stop messages for every session anyway. > It is also incorrect to include a Called-Station-Id in > Accounting-On/Accounting-Off to scope to a BSS as an Accounting-On > cannot be sent on this basis. Has there been any consensus check on this interpretation in a suitable IETF group? I don't think I'd fully agree with the interpretation of a single physical device with multiple radios (whether virtual or real) always counting as a single NAS or that there wouldn't be a NAS per BSS. That said, I also realize that there are different ways of implementing RADIUS clients for IEEE 802.11 APs. In some of the wireless switch cases with a shared management entity, it may very well be the case that there is a single RADIUS client (NAS?) per multiple APs and/or BSSs. However, that does not mean that the design with a RADIUS client per BSS would be any less viable option. > Alan, really helpfully, put up the following about this issue: > http://freeradius.org/rfc/acct_status_type_subsystem.html > > Additionally, it does not seem correct to include a NAS-Port-Type in > Accounting-On/Accounting-Off, nor WLAN-HESSID based on this context. > > I am also incidentally curious now if the proposed Subsystem-on and > Subsystem-Off should support nesting for layered, sub-dependent > subsystems of a NAS. I'm not sure I agree with the "sending one accounting packet for each user is not scalable" part as far as IEEE 802.11 access points are concerned. I never considered Accounting-Off (or -On) as an optimization to avoid sending out Stop messages. Without a much clearer definition of what a NAS, a subsystem, and a session are (and especially when a session terminates), I'm not sure this description would really result in much better situation. If the proposed changes were to deprecate use of Accounting-On/Off and add a clear description of how Subsystem-On/Off are to be used and if there were also an example of how this maps to likely IEEE 802 use cases, this would sound like a more useful direction to me. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap