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: Mário Luzeiro
Subject: Re: [lwip-users] https mbed TLS lwip
Date: Wed, 19 Feb 2020 13:15:53 +0000

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



reply via email to

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