lack of textual messages in the logs

defanor defanor at uberspace.net
Sat Jul 8 09:13:39 PDT 2017


> 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.



More information about the Hostap mailing list