Enterprise Supplicant Hangs When Connection Unsuccessful (CYW943907AEVAL1F)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

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
1 Solution

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
4 Replies
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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?

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

0 Likes

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

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