I am trying to use bare-metal "lwip_httpssrv_mbedTLS" to build HTTPS client side.
Can you tell me if there is a sample code I can use? Or is there anyone who can tell me how to build HTTPS client based on MbedTLS and LWIP raw API?
I am using MbedTLS sample server. And it works fine...
I am using it as my template and build client side. Found the following problems:
1. After it connects to https server, and starting handshake with 300 bytes.
message length: 300, out_left: 300, at line 2771 in file .ssl_tls.c
[WRITE] len = 300 ; state = 2
16 03 01 01 27 01 00 01 23 03 03 d9 80 b7 3e 2c 2a 17 27 25 e5 60 a5 71 c2 79 64 17 72 1b e8 df 7a 70 00 fe f5 81 ba eb dd d1 db 00 00 b2 c0 2c c0 30 00 9f c0 ad c0 9f c0 24 c0 28 00 6b c0 0a c0 14 00 39 c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e c0 23 c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2 00 ab c0 a7 c0 38 00 b3 c0 36 00 91 c0 ab 00 aa c0 a6 c0 37 00 b2 c0 35 00 90 c0 aa 00 9d c0 9d 00 3d 00 35 c0 32 c0 2a c0 0f c0 2e c0 26 c0 05 c0 a1 00 9c c0 9c 00 3c 00 2f c0 31 c0 29 c0 0e c0 2d c0 25 c0 04 c0 a0 00 ad 00 b7 00 95 00 ac 00 b6 00 94 00 a9 c0 a5 00 af 00 8d c0 a9 00 a8 c0 a4 00 ae 00 8c c0 a8 c0 08 c0 12 00 16 c0 34 00 8f 00 0a c0 0d c0 03 00 93 00 8b 00 ff 01 00 00 48 00 00 00 10 00 0e 00 00 0b 6f 73 2e 6d 62 65 64 2e 63 6f 6d 00 0d 00 16 00 14 06 03 06 01 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 00 23 00 00
ssl->f_send() returned 300 (-0xfffffed4) , at line 2777 in file .ssl_tls.c
Then, after that keep reading, but no any message from https server...
2. If I send the wrong handshake or change the length != 300, I can see there is packet received on http_recv on server side, and sent "bad client hello".
Can anyone tells me if my testing way is fine? And how to fix the problem?
Continuing with the follow up,
Currently we do not provide examples for HTTPS client on the Kinetis and LPC SDKs. So, we will have to rely on existing examples for other platforms. Here are our options:
1 Check the I.MX RT1060 SDK HTTPs client example (lwip_httpscli_mbedTLS_freertos).
Its goal it is to connect to https://os.mbed.com/media/uploads/mbed_official/hello.txt
and print a Hello world! message.
This example is built upon the Amazon freeRTOS . To port this client demo, for example to the FRDM-K64F, you will need to be aware of several differences across the I.MX RT and Kinetis peripherals such as RNG and ENET.
It could be helpful to also take a look at this example since the client functions or tasks are more simple that the server example functions.
2 Complementing your current path, where you are using the bare metal server example. You can take the MBED mbed TLS tutorial for as a reference to build you client application .
Regarding your questions, I am still not able to tell the cause of the error during the handshake process. However, my recommendation is to first try to connect to a server using HTTP and request data to the server, avoiding the use of a handshake. Then add the TLS layer for HTTPS.
Is there any other detail regarding your implementation that we could look at it?
1. I have tried to http server with http client...And without any problem for tcp request...
If I use tcp request to https server, it requires me to comment out the following lines in tcp_output(struct tcp_pcb *pcb)
//if (tcp_input_pcb == pcb)
then, https server can receive the request properly...
2. I am using FRDM-K64F as https server. and FRDM-K66F as https client. Both are using MCUXpresso 11.2 with SDK 2.8.0
After TCP connection is created, call the following function to do handshake. I can't get any response from HTTPS server. I checked there is no any data received on HTTPS server. Then I comment several line in tcp_output, HTTPS can get the handshake request from Https client.
But, When I tested with HTTP server, it works fine, no need to do anything in tcp_output, looks like to me, it is related to handshake function or something else, like LWIP stack function?
Please help me to fix this problem?
static int tcp_client_send(struct tcp_pcb *tpcb, struct client_HNS * es)
struct pbuf *ptr;
err_t wr_err = ERR_OK;
// uint8_t count_test;
if ((ret = mbedtls_ssl_set_hostname(&ssl, "os.mbed.com" )) != 0 )
PRINTF( "\r\nfailed ! mbedtls_ssl_set_hostname returned %d", ret );
// Start the TLS handshake
PRINTF("\r\nStarting the TLS handshake...");
ret = mbedtls_ssl_handshake(&ssl);
} while(ret != 0 && (ret == MBEDTLS_ERR_SSL_WANT_READ || ret == MBEDTLS_ERR_SSL_WANT_WRITE));
if (ret < 0)
PRINTF("\r\nmbedtls_ssl_handshake() returned -0x%04X", -ret);
PRINTF("\r\nSuccessfully completed the TLS handshake");
Unfortunately, I am not able to let you know how to fix the issue within the function that you provided me.
My guess is that you will need to perform further validation in your code before performing the handshake and call the function mbedtls_ssl_init(&(tlsDataParams.ssl));
If it helps you may try to check the https_client_tls_init() function on the RT1050 client example.
While trying to understand your issue, I have ported the RT1050 HTTPS client to the FRDM-K64F. I was able to read a hello world from the MBED server. with the K64.
The project that I ported it is attached just as an additional reference.
My apologies for the delayed repy, I hope this helps!
Please try again to download the project from my previous reply, it seems that the virus scan that did not let you previously, just finished.
Please take into account the following:
I cannot guarantee that the project that I am sharing it will work as expected on all situations, therefore it is aimed to serve just as a reference project. I strongly recommend to use and report any errors from official SDK example projects.
I hope this helps,
I tried the sample and looks fine.
Now, I tried to create the new project for FRDM-K66F and didn't work.
I found the problem is related to heap_4.c to release the memory because the new project wizard is using heap_4.c instead of heap_3.c.
Do you know how to generate the new FreeRTOS project to use heap_3.c? Have you have any chance to try on the baremetal environment by using LWIP RAW API?
I saw the project takes about 162K RAM. Do we really need that much? I tried to reduce the size of heap, like 64K, it does not work...The reason I want to reduce the heap size is because my project needs more RAM on that. My project based on baremetal http server is about 162K total RAM. Looks like it is not enough for FreeRTOS based MbedTLS based http server?
You a have a good point , the example of HTTPS client (that I shared with you), takes up to 162K of SRAM Upper , with default options.
Memory region Used Size Region Size %age Used PROGRAM_FLASH: 225360 B 1 MB 21.49% SRAM_UPPER: 162368 B 192 KB 82.58% SRAM_LOWER: 0 GB 64 KB 0.00% FLEX_RAM: 0 GB 4 KB 0.00%
To get more a better SRAM distibution you may try do the following
A) Manually allocate variables on the SRAM lower (which has up to 64 KB)
B) Move global data variables to the SRAM lower using project settings: .
This will free SRAM upper further, and will make use of SRAM lower, please refer to the image info perspective of the project:
You can also check the image info-> memory contents and image_info->call graph to get to know the highest memory consumers.
There are plenty optimizations that we could make, the following Erich Styger post on MCU on ecplise provides a good selection of techniques and tips to optimize memory consumption:Tutorial: How to Optimize Code and RAM Size
According to my understanding, the project that I attached it is using the heap3.c, however I am not an expert in this topic:
/* Used memory allocation (heap_x.c) */ #define configFRTOS_MEMORY_SCHEME 3
My apologies for the delayed reply,
I hope this could help,
Thank you for your information.
I tried to change the configuration "#define configFRTOS_MEMORY_SCHEME 3" and looks like there is no difference. And it still uses heap_4.c.
Do you have any chance to make sample project to work in bare-metal environment?
Thank you for your reply and providing your results.
Currently , I have no chance to move the example to the Bare-metal environment and I am not sure If I can in the future.