On Fri, Nov 14, 2008 at 12:17 AM, <tnt@kalik.net> wrote:
"User "goa" connects and when he turns machine off, new user "host/filteria"(his machine name) appears. Maybe the problems is inside hostapd(which I can't find), but I don't understand why "host/filteria" is updated with "goa" info."
It happened because hostapd kept the session id and changed the identity. Accounting for user goa was abandoned and session was attributed to the new identity.
hostapd can do that if it has a "valid" reason. You obviously have a problem with that. But don't blame freeradius for working correctly. hostapd is not working the way you expect it to.
The following RFC 3580 Chapter 2.1 text is one reason for hostapd behavipr: "Within [IEEE80211], periodic re-authentication may be useful in preventing reuse of an initialization vector with a given key. Since successful re-authentication does not result in termination of the session, accounting packets are not sent as a result of re-authentication unless the status of the session changes. For example:" As far as I can tell, that is describing multiple re-authentications for a single RADIUS session. Should the Supplicant decide to change its identity (e.g., switch between user and machine credentials) without stopping the session (disassociate/EAPOL-Logoff), I don't see how the Authenticator (NAS) should handle this case. It sounds like you are asking to arbitrarily pick the first identity (or create a new session, which would not comply with this RFC 3850 text) while hostapd is arbitrarily picking the last used identity within the same session. - Jouni