It looks like what is happening here is a re-authentication using machine credentials within the same IEEE 802.11 association. If the client would have re-associated, hostapd should have started a new session and in this case, there would have been start/stop acct with "goa" and then start/stop with "hoast/filteria" (using different session id).
Since I do not have a debug log from hostapd, I don't know what exactly happened here, but it is possible that there should have been another accounting session if the Supplicant sent an EAPOL-Logoff message without re-association. hostapd would not terminate the session in that case currently, but that's something I could consider changing in a way that a new session would be initialized if the client continues using the association after EAPOL-Logoff (e.g., by performing a new authentication). Still, it would be possible for the User-Name to change even within the same accounting session if the client does not send EAPOL-Logoff, but changes identity within the same association.
Yes. And hostapd reacted to that by reauthenticating the new username. Than it decided to keep the same session id. But to change the User-Name for accounting. If the session was to remain the same, (accounting) User-Name should have stayed the same as well and not changed to the new one. Ivan Kalik Kalik Informatika ISP