debugging EAP-TLS on Wiced 3.7.0-3, server-hello failing

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

cross mob
JoNa_2236316
Level 1
Level 1

Can anyone help with this error we encountered while debugging EAP-TLS on Wiced 3.7.0-3:  "Error with TLS client handshake 5042, TLS handshake failed".   It appears we did receive responses from the server including 1336-byte and 399-byte data packets but the EAP-TLS authentication sequence quits due to this error.

0 Likes
1 Solution
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

Hello John,

The error that you mentioned stands for NO DATA during the handshake process. But you have mentioned about two received packets. We were not able to recreate the issue here when we are using ThreadX RTOS.  Eventually, the issue was found out to be RTOS specific where an enum was differently optimized. We also advise you to upgrade to latest SDK as there were some memory related bugs in the 3.7.0.3 version of SDK as already mentioned.

View solution in original post

0 Likes
8 Replies
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

sdk-3.7.0-3 has memory leak bug in TLS library. Don't use it.

The memory leak is fixed by sdk-3.7.0-7.

RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

Hello John,

The error that you mentioned stands for NO DATA during the handshake process. But you have mentioned about two received packets. We were not able to recreate the issue here when we are using ThreadX RTOS.  Eventually, the issue was found out to be RTOS specific where an enum was differently optimized. We also advise you to upgrade to latest SDK as there were some memory related bugs in the 3.7.0.3 version of SDK as already mentioned.

0 Likes

Raktim Roy wrote:

Hello John,

We were not able to recreate the issue here when we are using ThreadX RTOS.  Eventually, the issue was found out to be RTOS specific where an enum was differently optimized

Can you explain a bit about why it is RTOS specific.

Does it work for FreeRTOS?

Since WICED claims to support both ThreadX and FreeRTOS, please make sure it works for both RTOS.

0 Likes

The RTOS John used was GreenHills RTOS which was optimizing an enum differently. After fixing that enum issue, we were able to see the server hello in Wireshark log. It should work fine with FreeRTOS and LwIP combination.

Do you have a standard test procedure to test EAP-TLS/PEAP?

I mean using console join_ent command, is there anything you need to modify to test EAP-TLS/PEAP?

0 Likes

I am trying to list out a basic outline of the procedure.

  1. Put the certificates in Wiced-SDK\libraries\utilities\command_console\wifi\certificate.h.
  2. In n "command_console_wifi.c" file mention proper eap_identity based on the user which was configured in back-end servers in function "join_ent " please change eap_identity appropriately.
  3. Modify the following tunables in console.mk file

        ifeq ($(PLATFORM),$(filter $(PLATFORM), BCM943364WCD1 BCM94343WWCD1 BCM94343WWCD2 BCM943438WCD1))

        GLOBAL_DEFINES += TX_PACKET_POOL_SIZE=10 \

        RX_PACKET_POOL_SIZE=10 \

        WICED_TCP_TX_DEPTH_QUEUE=13 \

        TCP_WINDOW_SIZE=131072

0 Likes

Hi rroy

When I test PEAP using ubuntu linux desktop, it has an option to connect enterprise AP without "CA".

i.e. I can connect without setting any ca/cert/key when using PEAP.

Is it fine to test PEAP without updating Wiced-SDK\libraries\utilities\command_console\wifi\certificate.h?

The changes for TX_PACKET_POOL_SIZ/RX_PACKET_POOL_SIZE/WICED_TCP_TX_DEPTH_QUEUE/TCP_WINDOW_SIZE is very strange. That changes means it takes more memory for the network stack.

Does that mean it won't work if using default settings on 4343W/43438 platforms?

0 Likes

Raktim Roy wrote:

I am trying to list out a basic outline of the procedure.

  1. Put the certificates in Wiced-SDK\libraries\utilities\command_console\wifi\certificate.h.

It seems does not make sense to hardcoded the certificate/key in

libraries\utilities\command_console\wifi\certificate.h because it needs to be user configurable.

But...

Consider your users want to enable EAP-TLS enterprise security.

It needs to allow users to update rootCA/certificate/key.

And if the user want to connect AWS-IoT, it needs another set of

rootCA/certificate/key which also needs to be user updatable.

Then it will run out of DCT space soon because rootCA/certificate/key

are quite big.

0 Likes