cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

Contributor II

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?

0 Likes
Reply
1 Solution
Contributor II

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!)

View solution in original post

0 Likes
Reply
4 Replies
Moderator
Moderator

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?

Contributor II

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!)

View solution in original post

0 Likes
Reply
Honored Contributor

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.

0 Likes
Reply
Contributor II

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

0 Likes
Reply