mbedtls problem with libcurl port to ESP32 #1327
Comments
That error is MBEDTLS_ERR_NET_RECV_FAILED. The "UNKNOWN ERROR CODE" is coming from mbedtls_strerror, it is what is returned when the error string for an error is not compiled in. In this case mbedTLS must be built with So I think it's very unlikely libcurl is at fault here. Can you try the same thing with the mbedTLS ssl_client1 sample program, with a few adjustments: diff --git a/programs/ssl/ssl_client1.c b/programs/ssl/ssl_client1.c
index fa70431..8bcf70a 100644
--- a/programs/ssl/ssl_client1.c
+++ b/programs/ssl/ssl_client1.c
@@ -62,9 +62,9 @@ int main( void )
#include <string.h>
-#define SERVER_PORT "4433"
-#define SERVER_NAME "localhost"
-#define GET_REQUEST "GET / HTTP/1.0\r\n\r\n"
+#define SERVER_PORT "443"
+#define SERVER_NAME "requestb.in"
+#define GET_REQUEST "GET / HTTP/1.1\r\nHost: requestb.in\r\nConnection: Close\r\n\r\n"
#define DEBUG_LEVEL 1
That should return the page and then say EOF, error MBEDTLS_ERR_SSL_CONN_EOF (-0x7280), and press a key to exit. Also re libcurl you should pass the options types exactly as specified, in other words for options that require a type |
|
I should have mentioned libcurl does set the custom callbacks for send and recv, see https://github.com/curl/curl/blob/curl-7_53_1/lib/vtls/mbedtls.c#L368-L371. So it turns out the error message just isn't built in but that |
|
Howdy ... I validated that the distribution of mbedtls being used has Searching the internet, I found the following: https://tls.mbed.org/discussions/bug-report-issues/ssl_write-and-ssl_read-timeout This could be a clue. Apparently we can get an error like this is we call mbed to receive data and there is no data to read. Since libcurl is the caller of mbed, that might point to libcurl as a potential issue. Running ESP32 supplied mbedtls samples seems to show that mbedtls as a framework works. If there is any other tests or diagnostics I can execute, please don't hesitate to let me know and I'll try and run them as quickly as possible. 19:31(Local) 2017-03-12 https://github.com/ARMmbed/mbedtls/blob/master/include/mbedtls/net_sockets.h#L42 which is defined as the symbol https://github.com/ARMmbed/mbedtls/blob/master/library/net_sockets.c#L485 19:49(Local) 2017-3-12 Searching even further ... I found this release note for libcurl ... https://curl.haxx.se/mail/archive-2017-02/0020.html Which contains a line that reads ... Might this issue be another instance of that? see also: #1223 |
|
Please make new posts instead of amending the last one like that, you asked a few more questions that nobody receiving e-mail updates would see since github only sends out the unedited original.
Usually yes, though there are some cases where the socket is temporarily set blocking. In the case of mbedtls handshake it is non-blocking.
if( ret < 0 )
{
if( net_would_block( ctx ) != 0 )
return( MBEDTLS_ERR_SSL_WANT_READ );
if( errno == EPIPE || errno == ECONNRESET )
return( MBEDTLS_ERR_NET_CONN_RESET );
if( errno == EINTR )
return( MBEDTLS_ERR_SSL_WANT_READ );
return( MBEDTLS_ERR_NET_RECV_FAILED );
}So static int net_would_block( const mbedtls_net_context *ctx )
{
/*
* Never return 'WOULD BLOCK' on a non-blocking socket
*/
if( ( fcntl( ctx->fd, F_GETFL ) & O_NONBLOCK ) != O_NONBLOCK )
return( 0 );
switch( errno )
{
#if defined EAGAIN
case EAGAIN:
#endif
#if defined EWOULDBLOCK && EWOULDBLOCK != EAGAIN
case EWOULDBLOCK:
#endif
return( 1 );
}
return( 0 );
}So maybe
Tthere was a bug that was fixed in 7.53 so that it would operate properly in non-blocking mode. You are using master and if that had something to do with it I think we'd see a different code path.
Please run the sample I linked to if you can. Also do other https websites show the same issue, and can you give us your curl_version() please. Thanks |
|
Also check curlx_nonblock and see how exactly it's setting nonblock, maybe the way mbedtls is checking it is different and not compatible for some reason. |
|
I realize now it doesn't make any sense that a blocking socket would return EAGAIN... so I'd look into the other things first |
|
@jay, Let me take the time to explain. My target for the port of libcurl is the ESP32 platform. This is a WiFi enabled MCU device (google ESP32). It supports the majority of the POSIX APIs and a TCP/IP stack based on LWIP. There is a development kit for the ESP32 called The core of the problem reported in this issue, and exactly as you diagnosed, is the function https://github.com/ARMmbed/mbedtls/blob/master/library/net_sockets.c#L270 All good. Now if we look at the ESP-IDF version, we find a subtle difference: https://github.com/espressif/esp-idf/blob/master/components/mbedtls/port/net.c#L204 The difference is that the ESP-IDF version doesn't look at "errno" from the environment but instead "asks the socket" for its last error. The reason being that the ESP32 is a multi-threaded preemptive environment and the use of the "global" errno shouldn't be used (which makes sense). However, look again at the ESP-IDF logic. The pertinent part I summarize below: The intent here in the I will now follow up with a report against ESP-IDF. MANY thanks for the assistance. Neil (a friend) |
|
No problem, thanks for the update. |
I am porting libcurl to the ESP32 environment. For non SSL operations, no issues at all. While testing SSL with mbedtls (which is what is supplied with the ESP32 development kit), I found that a handshake fails with a network level error of
-76which appears to be a timeout.My logic is as follows:
The error reported by libcurl is:
I then switched on tracing at the mbedtls level and captured the trace posted at the end of this report.
This problem is fully reproducible on my ESP32 environment. If needed, I can live chat and/or screen share as needed. The version of libcurl is the Github master as of 2017-03-12.
The text was updated successfully, but these errors were encountered: