- 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.
- 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!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Within join_ent, the function wifi_join() is called to connect to the AP. If that function fails, besl_supplicant_stop() and besl_supplicant_deinit() are called. So calling besl_supplicant_stop(&supplicant_workspace) again is not required. Generally a STA device retries 3 times by default if it fails to join an access point. Can you increase the value of WICED_JOIN_RETRY_ATTEMPTS to increase the join retry attempts?
- 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!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ChMa_3922746 wrote:
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!)
It would be even more dangerous if you add a timeout here.
The workspace->tls_context->context.state should eventually becomes MBEDTLS_SSL_HANDSHAKE_OVER,
if it never reach MBEDTLS_SSL_HANDSHAKE_OVER there must be bug somewhere.
Adding timeout here just hide the real bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the warning. I think the TLS handshake is possibly being terminated by the Radius server (not sure, though). It does work well with this workaround, however. I've tried a few corner cases and it keeps on truckin'.