Forgot to copy the list in, oops. So the salient point here: if the NAS-Port and NAS-Port-Id was going to change while populated with ifindex and ifname, we would expect to see a Stop and a Start for the related session with the same Acct-Multi-Session-Id. Cheers, Nick On Sun, Feb 7, 2016 at 10:46 AM, Nick Lowe <nick.lowe@xxxxxxxxxxxx> wrote: > Hi Jouni, > > It is perfectly legal and good practice to send both. The 'or' > definitely does not mean one-or-the-other. > > We see the same language used with: > > "Either NAS-IP-Address or NAS-Identifier MUST be present in a RADIUS > Accounting-Request." > > Later, however, we see: > > "[Note 1] An Accounting-Request MUST contain either a NAS-IP-Address > or a NAS-Identifier (or both)." > > The or there does not mean one-or-the-other. It is poorly worded. > > There is also clarification of expected behaviour is in RFC 3580 for > NAS-Port and NAS-Port-ID. > > 3.4. NAS-Port > > For use with IEEE 802.1X the NAS-Port will contain the port number of > the bridge, if this is available. While an Access Point does not > have physical ports, a unique "association ID" is assigned to every > mobile Station upon a successful association exchange. As a result, > for an Access Point, if the association exchange has been completed > prior to authentication, the NAS-Port attribute will contain the > association ID, which is a 16-bit unsigned integer. Where IEEE > 802.1X authentication occurs prior to association, a unique NAS-Port > value may not be available. > > 3.29. NAS-Port-Id > > This attribute is used to identify the IEEE 802.1X Authenticator port > which authenticates the Supplicant. The NAS-Port-Id differs from the > NAS-Port in that it is a string of variable length whereas the NAS- > Port is a 4 octet value. > > Conceptually and abstractly, the NAS-Port should contain the > association id only when it is available. When it is not, we need to > do something sensible. > Presently, hostap will usually always send 0, which is invalid. It > makes more sense to send the ifindex rather than omit the attribute. > This allows us to distinguish sessions by virtual interface (aka VAP) > at the RADIUS server. It is useful from a compartmentalisation > perspective, and can be used when constructing a GUI to show live > sessions that are being accounted for. > > The NAS-Port-Id, again allows us to distinguish sessions by virtual > interface (aka VAP), but can contain a human readable and friendly > ifname showing the radio and virtual interface index. > For example: wifi0.1, wifi1.1 > > It is again useful from a compartmentalisation perspective, and can be > used when constructing a GUI to show live sessions that are being > accounted for - this time with that friendly name. > > The key point is that we should not change the value of the NAS-Port > attribute that is accounted with once we start sending it for an > individual session. This is because breaks many, many things at RADIUS > servers in the default configuration. > > For example: > > http://freeradius.org/radiusd/man/rlm_acct_unique.txt > > When a related session is created, however, for which we must see a > Stop and a Start and with the same Acct-Multi-Session-Id, it is > perfectly fine and usually expected for the value to be different. > > Cheers, > > Nick _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
