wpa eap-tls failure on a uClinux distro port
Tue Jun 13 04:25:34 PDT 2006
Thanks for your quick response. Actually after I send you the mail about
the eap-tls failure I had success with
wpa_supplicant in WPA 1x working on ARM platform with uClinux, so thanks
first of all for wpa_supplicant. ;-)
Jouni Malinen wrote:
> On Tue, Jun 06, 2006 at 11:26:16AM +0300, Stavros Markou wrote:
>> I have ported the latest stable wpa_supplicant to uClinux for ARM
>> architecture and it works great for WPA-PSK . Now I am trying to
>> use WPA 1x authentication and I cannot pass the EAP-REQUEST EAP-RESPONSE
>> stage. I am using openssl-0.9.7c which is reported to work with the
>> supplicant . Is there something I need to check for the openssl or
>> wpa-supplicant ?
> I've seen wpa_supplicant working with both uClinux and ARM; though, if I
> remember correctly, not with the combination of both. I was using a
> newer version of OpenSSL, though.
>> SSL: Received packet(len=6) - Flags 0x20
>> EAP-TLS: Start
>> SSL: eap_tls_process_helper - tls_out_len : 0
>> SSL: eap_tls_process_helper -BEFORE REASSEMBLE!!!!
>> EAP-TLS: TLS processing failed
> This is failing for the first message of TLS handshake (ClientHello), so
> there hasn't really been any processing that OpenSSL would have done
> before this apart from configuration. Have you tried using OpenSSL with
> any other program on that device?
I know that there wasn't any processing for Openssl because inside
eap_tls_common.c in function :
eap_tls_process_helper the data->tls_out_len was zero msg was null and I
was returning from the procedure.
So, what I did is putting something like this :
(/ thought that if there are not in_data -> in_len == 0 then there is no
reason to call reassemble ???)/
msg = eap_tls_data_reassemble(sm, data, in_data, in_len,
if (msg == NULL)
return need_more_input ? 1 : -1;
and I had success. The only problem I had with openssl was that the DK I
am working with had the wrong time (Jan 1 1970)
so the only problem was the validity of the ceritficate (notBefore date
> I would also consider trying to comment out some of the certificate/
> private key parsing calls to OpenSSL. wpa_supplicant is trying number of
> different format options (DER/PEM/PKCS#12/...) and this shows up as a
> large number of OpenSSL errors. I haven't seen this causing issues, but
> I cannot think of anything else that could be triggering this kind of
> behavior. It would be enough to just hardcode tls_openssl.c to use the
> format that you happen to be using in the configuration.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 300 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060613/8291b993/attachment.vcf
More information about the Hostap