lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] https mbed TLS lwip


From: Trampas Stern
Subject: Re: [lwip-users] https mbed TLS lwip
Date: Wed, 19 Feb 2020 09:29:13 -0500

right now I have the following settings:
#define MEM_SIZE                 12 * 1024
#define MEMP_NUM_TCP_PCB                20
#define MEMP_NUM_TCP_PCB_LISTEN        10
#define MEMP_NUM_TCP_SEG                20
#define PBUF_POOL_SIZE                 20
#define TCP_MSS                 1460

/**
 * TCP_WND: The size of a TCP window.  This must be at least
 * (2 * TCP_MSS) for things to work well
 */
#define TCP_WND               (10 * TCP_MSS)

/**
 * TCP_SND_BUF: TCP sender buffer space (bytes).
 * To achieve good performance, this should be at least 2 * TCP_MSS.
 */
#define TCP_SND_BUF             (4 * TCP_MSS)

It appears that I am getting handshake failures...

ssl_tls.c 2744: <= fetch input
ssl_tls.c 4058: input record: msgtype = 21, version = [3:3], msglen = 2
ssl_tls.c 2538: => fetch input
ssl_tls.c 2699: in_left: 5, nb_want: 7
ssl_tls.c 2723: in_left: 5, nb_want: 7
ssl_tls.c 2744: <= fetch input
ssl_tls.c 5172: got an alert message, type: [2:46]
ssl_tls.c 5180: is a fatal alert message (msg 46)
ssl_tls.c 8096: <= handshake
ERROR:    altcp_tls_mbedtls.c  283: mbedtls_ssl_handshake failed: -0x7780




On Wed, Feb 19, 2020 at 8:16 AM Mário Luzeiro <address@hidden> wrote:
Hi Trampas,

I'm referring to SSL Cache, not (necessarily) MCU Cache (but yes, enable it if possible)
but I guess it is already enabled by default configuration.

The first time the browser connects, it will take a long time to compute the session keys (or whatever)
but once it is cached, the next connections can reuse it and connect faster.

Try increase even more MEMP_NUM_TCP_PCB and MEMP_NUM_TCP_PCB_LISTEN as much as possible.
Try play also with TCP_MSS and TCP_WND

Mario

________________________________________
From: lwip-users <lwip-users-bounces+mrluzeiro=address@hidden> on behalf of Trampas Stern <address@hidden>
Sent: 18 February 2020 19:12
To: Mailing list for lwIP users
Subject: Re: [lwip-users] https mbed TLS lwip

Mario,

Thanks for the response, enclosed is my lwip options.

I have set up my GMAC (Ethernet peripheral) to use a non-cached section of ram due to DMA, however I have also disabled the cortex M7 data cache just in case.  Disabling the data cache did not make a difference.

I have noticed that the code appears to be more reliable when I have debug messages turned on (timing problem?).  Here is a following terminal debug log output:

ttpd.c 2804: http_accept 20456c0c / 0
httpd.c 2804: http_accept 20456b30 / 0
httpd.c 2647: http_poll:  pcb=20456b30 hs=20451c14 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456c0c hs=20451a10 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456b30 hs=20451c14 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456c0c hs=20451a10 pcb_state=ESTABLISHED
altcp_tls_mbedtls.c  283: mbedtls_ssl_handshake failed: -0x7780
httpd.c 2599: http_err: Connection closed., pcb: 20456c0c
altcp_tls_mbedtls.c  283: mbedtls_ssl_handshake failed: -0x7780
httpd.c 2599: http_err: Connection closed., pcb: 20456b30
httpd.c 2804: http_accept 20456b5c / 0
httpd.c 2647: http_poll:  pcb=20456b5c hs=20451a0c pcb_state=ESTABLISHED
httpd.c 2804: http_accept 20456be0 / 0
httpd.c 2647: http_poll:  pcb=20456b5c hs=20451a0c pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456be0 hs=20451c10 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456b5c hs=20451a0c pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456be0 hs=20451c10 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456b5c hs=20451a0c pcb_state=ESTABLISHED
httpd.c 2669: http_poll: too many retries, close
httpd.c  634: Closing connection 20456b5c,
httpd.c 2647: http_poll:  pcb=20456be0 hs=20451c10 pcb_state=ESTABLISHED
httpd.c 2647: http_poll:  pcb=20456be0 hs=20451c10 pcb_state=ESTABLISHED
httpd.c 2669: http_poll: too many retries, close
httpd.c  634: Closing connection 20456be0,

As you see I am getting handshake failed, but not sure this is root cause as I get this when the website works too.

I am thinking it could be a race condition bug, as that adding debug messages reduces error,  but would have a hard time thinking that such a bug would have existed this long.  Also I am running the code without an RTOS such that code for the most part runs atomically.

Trampas



On Tue, Feb 18, 2020 at 1:57 PM Mário Luzeiro <address@hidden<mailto:address@hidden>> wrote:
Hi Trampas,

I had an experience with lwip, mbedTLS and https (all using latest versions from repositories)
It took a loooong time to me to make it (kinda) work.

The problems I had (some similar than yours and lots of others) was a combinations of multiple factors:
- MCU drivers bugs (on my case the ST DMA issue).
- MCU limited resources: use the faster options you can get for encryption, limit the use of memory and allow TLS cache usage.
- Memory and parameter configurations: since browsers can fire 4 .. 8 connections to get the page, you will need to allow all that connections to be accepted.
- Parameter configurations: you will have to fine tune your parameters to your use case and resources limitation.

You will have to debug a lot, using webbrowser, wireshark and so on.. until o find the best parameters for you.
What you are describing looks the browser can make the first connections and then it cannot make new connections because there are no slots left.

Mario

________________________________________
From: lwip-users <lwip-users-bounces+mrluzeiro=address@hidden<mailto:address@hidden>> on behalf of Trampas Stern <address@hidden<mailto:address@hidden>>
Sent: 18 February 2020 18:40
To: Mailing list for lwIP users
Subject: [lwip-users] https mbed TLS lwip

I am having a problem with the lwip and mbed TLS.  I find that usually after reboot chrome can access my lwip https server and the first load of the web page seems to work. If I refresh the website then it seems to fail I have noticed in Chrome that I get the following errors:

[image.png]

Since the firmware usually works without a problem after reboot I assume there is some sort of firmware bug (malloc not being free, etc).  I have not been able to nail down what the problem is.

Anyone have any suggestions?

Thanks
Trampas
_______________________________________________
lwip-users mailing list
address@hidden<mailto:address@hidden>
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

[Prev in Thread] Current Thread [Next in Thread]