Potential bug in src/eap_peer/eap_tls_common.c causes wpa_supplicant to stop trying

[Mike Gerow]

tl;dr: As of commit 1cb3ad73623c20498a9163730c43563a869cf4a0 is it a
bug that there isn't a "return -1" after
src/eap_peer/eap_tls_common.c:206 ?

We're using wpa_supplicant with eap-tls and having it use a PKCS#11
module for signing operations. Sometimes we get log entries like this:

Jan 26 16:07:39 example.com wpa_supplicant[3291]: em1:
CTRL-EVENT-EAP-STARTED EAP authentication started
Jan 26 16:07:39 example.com wpa_supplicant[3291]: em1:
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
Jan 26 16:07:39 example.com wpa_supplicant[3291]: ENGINE: cannot load
private key with id 'id_04' [error:26096080:engine
routines:ENGINE_load_private_key:failed loading private key]
Jan 26 16:07:39 example.com wpa_supplicant[3291]: em1:
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
Jan 26 16:07:41 example.com wpa_supplicant[3291]: em1:
CTRL-EVENT-EAP-FAILURE EAP authentication failed

Which is all well and good, it sounds like our our PKCS#11 back-end
(opencryptoki in this case) is complaining, but the problem is that
wpa_supplicant refuses to re-try starting the PKCS#11 module and
authing ever again until the machine is rebooted. Even disconnecting
and reconnecting in NetworkManager didn't cause it to re-auth.

Digging through the source src/eap_peer/eap_tls_common.c:206 looked
suspicious, as if it was failing to properly report the failure in
this case. Adding a "return -1" in this case seemed to fix the issue
in that it would at least retry authing when disconnecting and
reconnecting in NetworkManager.

So it looks like this function should be reporting the error to the
caller... but I don't know enough about the wpa_supplicant code to
know for sure if this was an accident or purposeful.

-- 
Mike Gerow
gerow at google.com