> These wpa_msg() calls with defined prefixes like that > WPA_EVENT_DISCONNECTED are really meant for upper layer programs, not > users, to parse.. Such an upper layer component could then convert this > to more user friendly indication. I see, but while the events like WPA_EVENT_DISCONNECTED get handled by the upper layer programs, the reasons such as WLAN_REASON_DEAUTH_LEAVING still don't seem to be getting into the logs in an user-accessible form with e.g. NetworkManager: for instance, sometimes there's just a log entry from wpa_supplicant (it runs as a systemd service on the system where I've observed it, so maybe it was just its stdout/stderr output that got caught, if wpa_supplicant doesn't write into syslog or journald explicitly), pointing that the reason of a disconnect is 4, followed by one from NetworkManager, pointing that it's -4. I'm not certain if it was produced by the wpa_msg function though: this code sample was just the first one I've found, and the format seemed to match the one I saw in the logs (but the one from the logs had reason=4; that is, WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY, not WLAN_REASON_DEAUTH_LEAVING). That was observed with wpa_supplicant version 2.4. Seems like it's one of those situations where it can be improved in either place (wpa_supplicant or an upper layer program), but one could invoke wpa_supplicant manually, and it's used by a few other programs -- so perhaps it would be nicer (particularly for end users) to provide textual descriptions by wpa_supplicant itself in order to cover most of the situations at once. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
