- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When the Enterprise supplicant fails to connect (e.g., by employing settings on the radius server that prevent authentication of the WICED device), then I am calling the following function in order to reset things and "start again":
besl_supplicant_stop(&supplicant_workspace)
However, calling the function hangs because it waits indefinitely for the thread to exit when calling:
host_rtos_join_thread( &host_workspace->thread )
This function behaves normally if the WICED client is authenticated and connected to the access point. For example, if the access point goes down, then up, then I need to call besl_supplicant_stop and besl_supplicant_deinit in order to recover the link. This works Ok.
Any ideas?
Solved! Go to Solution.
- Labels:
-
ispn:38946:1:0
-
l1:314:1:0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. I tried increasing it to 5 and 10, but at the end the processor freezes. Only the watchdog can kick it back to life. I turned on debugging, and got:
Joining : ap_ssid_1234
[supplicant_external_event_handler()] : L677 : Event type = [16], Status = [0], Reason = [0], Flags = [1]
Supplicant received link event
supplicant_external_event[supplicant_external_event_handler()] : L677 : Event type = [16], Status = [0], Reason = [2], Flags = [0]
Supplicant received link event
Supplicant result = [6011]
Signal supplicant thread to exit
Wait for supplicant thread to exit
TLS handshake failed with error = [4]
Cleanup TLS Agent event queue
Cleanup of TLS Agent event queue done!
Note that, in contrast, here is a successful stop:
Supplicant result = [0]
Signal supplicant thread to exit
Process EAPOL packet
Terminate TLS agent and PEAP threads, if running
Wait for supplicant thread to exit
Unregister EAPOL handler
Reset supplicant event handlers
Cleanup supplicant event queue
Cleanup supplicant outgoing packet queue
Deinit and free host queues
Delete supplicant thread
MEM : FREE : Free supplicant thread stack
MEM : FREE : Free supplicant host workspace
MEM : FREE : Free supplicant defragmentation buffer
Deinitialize TLS context, cert and identity
Exit success!
With the above results, I did a bit of digging and found that the following while loop in the function supplicant_phase2_thread() never exits in the failing case:
while ( workspace->tls_context->context.state != MBEDTLS_SSL_HANDSHAKE_OVER )
{
host_rtos_delay_milliseconds( 10 );
}
By adding a time-out to the while loop, it can exit and then the supplicant can be stopped normally.
(Note: while loops like this are very dangerous when it comes to protocol states!)