And which Access-Accept would this be referring to? The problem here is that there can be multiple authentication runs (re-authentication based on supplicant request or authenticator policy) and should the supplicant change its identity, the second Access-Accept is likely to have a different identity in that case.
While it may be reasonable to arbitrarily decide to use User-Name (if present) from the first Access-Accept, it does not sound like that good of an idea for a RADIUS server to depend on this behavior based on current RADIUS RFCs.
And it doesn't. Freeradius has abandoned the session for first username and gone on with the changed identity. It followed what NAS has done correctly. "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. Ivan Kalik Kalik Informatika ISP