Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32 version will not compile #2

Open
dmarc1234 opened this issue Feb 6, 2023 · 13 comments
Open

ESP32 version will not compile #2

dmarc1234 opened this issue Feb 6, 2023 · 13 comments

Comments

@dmarc1234
Copy link

Hello

I have been trying to get your code to compile for the ESP32 but the beginSecure() routine cannot be found.

Any ideas ?

@ManoharGuggilla
Copy link

enable the macro ASYNC_TCP_SSL_ENABLED=1

@dmarc1234
Copy link
Author

This macro is already defined, but on closer inspection there is no beginSecure() routine in AsyncTCP.cpp ?

I am using use https://github.com/yubox-node-org/AsyncTCPSock.git and https://github.com/yubox-node-org/ESPAsyncWebServer but beginSecure() is not present.
Only the ESP8266 version ESPAsyncTCP.cpp supports beginSecure()

Is it possible to get this example to compile for ESP32 ?

@ManoharGuggilla
Copy link

i am able to compile this one in platform.io but getting run time error

T tiT- failed: mbedtls_ssl_setup returned -0x7f00
T tiT- SSL - Memory allocation failed
T tiT- MbedTLS message code: -32512

and sometimes

assert failed: tcp_update_rcv_ann_wnd IDF/components/lwip/lwip/src/core/tcp.c:951 (new_rcv_ann_wnd <= 0xffff)

@dmarc1234
Copy link
Author

Thank you for having a look.

Can you send a link to the AsyncTCP.cpp and AsyncTCP.h files you are using, there is a definition of 'beginSecure()' defined within the AsyncTCP.h I have but no 'beginSecure()' within AsyncTCP.cpp that I am using from the libraries above, which is strange.

@Bmooij
Copy link
Owner

Bmooij commented Feb 8, 2023

The beginSecure function is located in the modified AsyncTCP library in the mbed-tls branche.
This is stated in the platform.ini file

I don't know if this version is still working with the current ESP32-arduino library version 2.x.
This is tested with version 1.x of the ESP32-arduino library, 3 years ago and is no maintained ever since.

@dmarc1234
Copy link
Author

Hi @Bmooij

Downloaded that library and replaced the current AsyncTCP file set with the new.

I am able to get it to compile up until the receiving the following two errors:

tcp_mbedtls.cpp:760: undefined reference to _tcp_write4ssl(tcp_pcb*, char const*, unsigned int, unsigned char, void*)
tcp_mbedtls.cpp:760: undefined reference to _tcp_output4ssl(tcp_pcb*, void*)

I think these are due to the jump pad definitions in AsyncTCP.cpp as follows:

// Jump pads for _tcp_*4ssl function below to get access to _closed_slot.
// I'm sure there has to be a better way to do this...

esp_err_t AsyncClient::_tcp_output4ssl(tcp_pcb * pcb) {
    return _tcp_output(pcb, _closed_slot);
}

esp_err_t AsyncClient::_tcp_write4ssl(tcp_pcb * pcb, const char* data, size_t size, uint8_t apiflags) {
    return _tcp_write(pcb, _closed_slot, data, size, apiflags);
}

but error line pointer '760' is completely wrong as it points to a item->arg = arg; line.

Still using the original 1.x of the ESP32-arduino library so hopefully can get it going, any ideas ?

@dmarc1234
Copy link
Author

Hi @Bmooij

Have managed to get that to compile and its working up to a point.

When requesting files that are < 2K things seem to work normally, but larger files cause an exception:

T async_tcp- tcp_ssl_write(3ffe2b54, 3fff9bb8, len=4253)
T tiT- failed: mbedtls_ssl_setup returned -0x7f00
:T-a2512cbed4LACmeleage4cod locat0o3Ffai160
         tcp- tcp_ssl_send: tcp_write(3ffe2b54, 3fff47ac, 2872, 3fffd044)
E (79943) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (79943) task_wdt:  - async_tcp (CPU 0/1)
E (79943) task_wdt: Tasks currently running:
E (79943) task_wdt: CPU 0: IDLE0
E (79943) task_wdt: CPU 1: IDLE1
E (79943) task_wdt: Aborting.
abort() was called at PC 0x400facbc on core 0

Backtrace: 0x4008e3f8:0x3ffbe170 0x4008e629:0x3ffbe190 0x400facbc:0x3ffbe1b0 0x40085815:0x3ffbe1d0 0x401b37a7:0x3ffbc120 0x400fc7f6:0x3ffbc140 0x4008c2a5:0x3ffbc160 0x4008aab1:0x3ffbc180
Backtrace:
Decoding stack results
0x4008e3f8: invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c line 155
0x4008e629: abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c line 170
0x400facbc: task_wdt_isr at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/task_wdt.c line 174
0x401b37a7: esp_pm_impl_waiti at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/pm_esp32.c line 492
0x400fc7f6: esp_vApplicationIdleHook at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/freertos_hooks.c line 63
0x4008c2a5: prvIdleTask at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/tasks.c line 3382
0x4008aab1: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

Looks like the Mbedtls process is taking too long and causing a TWDT timeout, any idea how this can be resolved.

@Bmooij
Copy link
Owner

Bmooij commented Mar 30, 2023

If you really know what you are doing, you could turn off the watchdog by setting CONFIG_ASYNC_TCP_USE_WDT to 0

build_flags = 
  -DCONFIG_ASYNC_TCP_USE_WDT=0

@dmarc1234
Copy link
Author

Thank you.

I did notice this compiler switch for code within _async_service_task() and I was wondering if that might be worth a try.

I suppose this was added to attach a TWDT to the current async_tcp task, but I cannot see an associated esp_task_wdt_reset() call to reset the TWDT so its bound to timeout if processing longer tasks.

I'll give it go and let you know.

@zekageri
Copy link

Funny because the original ( without tls) behaves the same

@dmarc1234
Copy link
Author

Added the config to the build flags and re-tested. It's stopped the exception from happening but the async_tcp task just locks up now so there is still something internally wrong, still looks like a corruption somewhere:

T tiT- failed: mbedtls_ssl_setup returned -0x7f00
T tiT- SSLT  Myno_ycp- occ_sson fad:ect
4282                                   : ti3-FMbed4LS messageFFode: , l512
T async_tcp- tcp_ssl_send: tcp_write(3ffe3c44, 3fff47ac, 2872, 3fffcaa8)

As you can see we get a setup fail, a memory corruption causing corrupted debug output and then it tries to write the data to the TCP connection but this is where the task locks up.
Could this be a buffer issue somewhere, where tcp_ssl is not allocating enough buffer or not freeing it up for larger pages.

@Bmooij
Copy link
Owner

Bmooij commented Apr 4, 2023

It looks like there is not enough free heap available.

How many connections where connected at the same time?
Did it happen on the first, second, third, etc request?

@dmarc1234
Copy link
Author

I made a modification to AsyncTCP.cpp to add a heap length output:

T async_tcp- tcp_ssl_write(3ffe2a18, 3fffce28, len=5744, heap=15400)
T async_tcp- tcp_ssl_send: ctx: 0x3FFF0644, buf: 0x3FFF4EDC, len: 5773
T async_tcp- tcp_ssl_send: tcp_write(3ffe2a18, 3fff4edc, 2872, 3ffe2ba8)
T async_tcp- tcp_ssl_send: tcp_output: 2872 / 5773
T async_tcp- tcp_ssl_send: ctx: 0x3FFF0644, buf: 0x3FFF5A14, len: 2901
T async_tcp- tcp_ssl_send: tcp_write(3ffe2a18, 3fff5a14, 2872, 3ffe2ba8)
T async_tcp- tcp_ssl_send: tcp_output: 2872 / 2901
T async_tcp- tcp_ssl_send: ctx: 0x3FFF0644, buf: 0x3FFF654C, len: 29
T async_tcp- tcp_ssl_send: tcp_write(3ffe2a18, 3fff654c, 29, 3ffe2ba8)
T async_tcp- tcp_ssl_send: tcp_output: 29 / 29
T async_tcp- tcp_ssl_recv: ctx: 0x3FFF0644, buf: 0x3FFF0D7C, len: 5
T async_tcp- tcp_ssl_recv: len: 5, recv_len: 0, pbuf_offsett 740, tlep_ bue len: s4_se
                                                                                      T  retc_tcp--0c7f00l
,T ot_- nbedTLS meuf_offsode: -32512atibytes: 71
                                     ync_tcp- tcp_ssl_read: return total_bytes: 0

As you can see the heap length is around 15K on the write before the corruption so I don't think it's a heap issue.

I have also increased the stack allocation to 8192 * 4 and the same corruption still happens.

Thought I was so close to getting working, just this last piece of the jigsaw to find.

Any help much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants