https mbed TLS lwip

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

https mbed TLS lwip

Trampas Stern
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Mario Luzeiro
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=[hidden email]> on behalf of Trampas Stern <[hidden email]>
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

image.png (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Trampas Stern
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 <[hidden email]> 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=[hidden email]> on behalf of Trampas Stern <[hidden email]>
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

lwipopts.h (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Mario Luzeiro
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=[hidden email]> on behalf of Trampas Stern <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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=[hidden email]<mailto:[hidden email]>> on behalf of Trampas Stern <[hidden email]<mailto:[hidden email]>>
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
[hidden email]<mailto:[hidden email]>
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Trampas Stern
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 <[hidden email]> 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=[hidden email]> on behalf of Trampas Stern <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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=[hidden email]<mailto:[hidden email]>> on behalf of Trampas Stern <[hidden email]<mailto:[hidden email]>>
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
[hidden email]<mailto:[hidden email]>
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

goldsimon@gmx.de
Trampas Stern wrote:
> right now I have the following settings:
> #define MEM_SIZE                 12 * 1024
> [..]
> It appears that I am getting handshake failures...
 
During runtime mbedTLS allocates hughe amounts of memory. Depending on your
configuration, this is routed to the lwIP heap (see altcp_tls_mbedtls_mem.c).
If so, this value is *much* too low!

The other values might be too low, too. Try to increase everything to the max
(that your system allows) and see how much you actually need by monitoring
lwip_stats.

Regards,
Simon


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Trampas Stern
I will increase more...  

I am monitoring for alloc failures, but not seeing any. 



altcp_mbedtls_state_t *
altcp_mbedtls_alloc(void *conf)
{
  altcp_mbedtls_state_t *ret = (altcp_mbedtls_state_t *)mem_calloc(1, sizeof(altcp_mbedtls_state_t));
  if (ret != NULL) {
    ret->conf = conf;
  }
  if (NULL == ret)
  {
 ERROR("Malloc failed");
  }
  return ret;
}

void
altcp_mbedtls_free(void *conf, altcp_mbedtls_state_t *state)
{
  LWIP_UNUSED_ARG(conf);
  LWIP_ASSERT("state != NULL", state != NULL);
  mem_free(state);
}

void *
altcp_mbedtls_alloc_config(size_t size)
{
  void *ret;
  size_t checked_size = (mem_size_t)size;
  if (size != checked_size) {
    /* allocation too big (mem_size_t overflow) */
 ERROR("Alloc failed");
    return NULL;
  }
  ret = (altcp_mbedtls_state_t *)mem_calloc(1, (mem_size_t)size);
  return ret;
}

On Wed, Feb 19, 2020 at 9:46 AM Simon Goldschmidt <[hidden email]> wrote:
Trampas Stern wrote:
> right now I have the following settings:
> #define MEM_SIZE                 12 * 1024
> [..]
> It appears that I am getting handshake failures...
 
During runtime mbedTLS allocates hughe amounts of memory. Depending on your
configuration, this is routed to the lwIP heap (see altcp_tls_mbedtls_mem.c).
If so, this value is *much* too low!

The other values might be too low, too. Try to increase everything to the max
(that your system allows) and see how much you actually need by monitoring
lwip_stats.

Regards,
Simon


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Trampas Stern
Does anyone have recommended configuration for https?  I have the following and still having problems:

#define MEM_SIZE                 42 * 1024
#define MEMP_NUM_TCP_PCB                20
#define MEMP_NUM_TCP_PCB_LISTEN        10
#define MEMP_NUM_TCP_SEG               100
#define MEMP_NUM_FRAG_PBUF              6
#define MEMP_NUM_PBUF                   8
#define PBUF_POOL_SIZE                 20
#define TCP_MSS                 1460
#define TCP_WND               (10 * TCP_MSS)
#define TCP_SND_BUF             (10 * TCP_MSS)

Maybe someone has an example lwipopts.h and config.h (for mbedtls) which works that I can compare? 

Thanks
Trampas


On Wed, Feb 19, 2020 at 10:45 AM Trampas Stern <[hidden email]> wrote:
I will increase more...  

I am monitoring for alloc failures, but not seeing any. 



altcp_mbedtls_state_t *
altcp_mbedtls_alloc(void *conf)
{
  altcp_mbedtls_state_t *ret = (altcp_mbedtls_state_t *)mem_calloc(1, sizeof(altcp_mbedtls_state_t));
  if (ret != NULL) {
    ret->conf = conf;
  }
  if (NULL == ret)
  {
 ERROR("Malloc failed");
  }
  return ret;
}

void
altcp_mbedtls_free(void *conf, altcp_mbedtls_state_t *state)
{
  LWIP_UNUSED_ARG(conf);
  LWIP_ASSERT("state != NULL", state != NULL);
  mem_free(state);
}

void *
altcp_mbedtls_alloc_config(size_t size)
{
  void *ret;
  size_t checked_size = (mem_size_t)size;
  if (size != checked_size) {
    /* allocation too big (mem_size_t overflow) */
 ERROR("Alloc failed");
    return NULL;
  }
  ret = (altcp_mbedtls_state_t *)mem_calloc(1, (mem_size_t)size);
  return ret;
}

On Wed, Feb 19, 2020 at 9:46 AM Simon Goldschmidt <[hidden email]> wrote:
Trampas Stern wrote:
> right now I have the following settings:
> #define MEM_SIZE                 12 * 1024
> [..]
> It appears that I am getting handshake failures...
 
During runtime mbedTLS allocates hughe amounts of memory. Depending on your
configuration, this is routed to the lwIP heap (see altcp_tls_mbedtls_mem.c).
If so, this value is *much* too low!

The other values might be too low, too. Try to increase everything to the max
(that your system allows) and see how much you actually need by monitoring
lwip_stats.

Regards,
Simon


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: https mbed TLS lwip

Trampas Stern
So I normally have a breakpoint enabled in _sbrk() to catch mallocs, but forgot to define the symbol to enable.  So I found out that Mbedtls is calling malloc(), and is using around 176k of heap space which seems to be excessive, 

I also tried refreshing page several times to see what the maximum heap storage goes up to and seems to stabilize at 176k, however after a few refreshes the system stops working and I get the following:
tcp_out.c 1097: tcp_enqueue_flags: queueing 394913:394914 (0x12)
tcp_out.c 1546: tcp_output_segment: 394913:394913
tcp_out.c 1268: tcp_output: nothing to send (0)
tcp_out.c 1268: tcp_output: nothing to send (0)
tcp_out.c 1097: tcp_enqueue_flags: queueing 396664:396665 (0x12)
tcp_out.c 1546: tcp_output_segment: 396664:396664
tcp_out.c 1268: tcp_output: nothing to send (0)
tcp_out.c 1268: tcp_output: nothing to send (0)
tcp_out.c 1268: tcp_output: nothing to send (0)

Note I am using mbedtls 1.16.4 and lwip version 2.1.2

Trampas

On Wed, Feb 19, 2020 at 11:05 AM Trampas Stern <[hidden email]> wrote:
Does anyone have recommended configuration for https?  I have the following and still having problems:

#define MEM_SIZE                 42 * 1024
#define MEMP_NUM_TCP_PCB                20
#define MEMP_NUM_TCP_PCB_LISTEN        10
#define MEMP_NUM_TCP_SEG               100
#define MEMP_NUM_FRAG_PBUF              6
#define MEMP_NUM_PBUF                   8
#define PBUF_POOL_SIZE                 20
#define TCP_MSS                 1460
#define TCP_WND               (10 * TCP_MSS)
#define TCP_SND_BUF             (10 * TCP_MSS)

Maybe someone has an example lwipopts.h and config.h (for mbedtls) which works that I can compare? 

Thanks
Trampas


On Wed, Feb 19, 2020 at 10:45 AM Trampas Stern <[hidden email]> wrote:
I will increase more...  

I am monitoring for alloc failures, but not seeing any. 



altcp_mbedtls_state_t *
altcp_mbedtls_alloc(void *conf)
{
  altcp_mbedtls_state_t *ret = (altcp_mbedtls_state_t *)mem_calloc(1, sizeof(altcp_mbedtls_state_t));
  if (ret != NULL) {
    ret->conf = conf;
  }
  if (NULL == ret)
  {
 ERROR("Malloc failed");
  }
  return ret;
}

void
altcp_mbedtls_free(void *conf, altcp_mbedtls_state_t *state)
{
  LWIP_UNUSED_ARG(conf);
  LWIP_ASSERT("state != NULL", state != NULL);
  mem_free(state);
}

void *
altcp_mbedtls_alloc_config(size_t size)
{
  void *ret;
  size_t checked_size = (mem_size_t)size;
  if (size != checked_size) {
    /* allocation too big (mem_size_t overflow) */
 ERROR("Alloc failed");
    return NULL;
  }
  ret = (altcp_mbedtls_state_t *)mem_calloc(1, (mem_size_t)size);
  return ret;
}

On Wed, Feb 19, 2020 at 9:46 AM Simon Goldschmidt <[hidden email]> wrote:
Trampas Stern wrote:
> right now I have the following settings:
> #define MEM_SIZE                 12 * 1024
> [..]
> It appears that I am getting handshake failures...
 
During runtime mbedTLS allocates hughe amounts of memory. Depending on your
configuration, this is routed to the lwIP heap (see altcp_tls_mbedtls_mem.c).
If so, this value is *much* too low!

The other values might be too low, too. Try to increase everything to the max
(that your system allows) and see how much you actually need by monitoring
lwip_stats.

Regards,
Simon


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users