You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are not using mbedTLS's "net" functions, instead we provide our own I/O layer which feeds data to mbedTLS from our C++ in-out streams. (This allows us to run our MbedTlsEngine over any stream - a memory stream for testing, a socket stream, or a thread IPC stream...) I would expect that it is fairly common for users to run mbedTLS over their own I/O abstraction, rather than using the "net" functions to hand raw sockets to mbedTLS.
For those of us using mbedtls_ssl_set_bio, we need to choose some return codes to use in our mbedtls_ssl_send_t and mbedtls_ssl_recv_t functions. We are using codes such as MBEDTLS_ERR_NET_RECV_FAILED, since we have to choose error codes that are allocated from among the mbedTLS numbers (we wouldn't want to return numbers that clash with a future allocation). Those are the natural return codes to be using. mbedTLS does kind-of assume that the return values from the send/receive functions are within its own space of allocated codes, since it checks for specific values from the functions, such as MBEDTLS_ERR_SSL_WANT_READ.
Would it be possible to build in the "_NET_" error codes, in error.c, even if MBEDTLS_NET_C is not defined? Otherwise - what codes are you expecting people to return from their mbedtls_ssl_send_t and mbedtls_ssl_recv_t functions? These codes represent a special case; even if customers are not using the "net" layer, the corresponding error numbers are still probably/possibly in use.
The text was updated successfully, but these errors were encountered:
@NWilson Thank you for raising this
Your use case is reasonable, and we will consider it. Note that this is not entirely according to Mbed TLS architecture, however the networking module is a bit of an exception, as MBEDTLS_NET_C defines the networking module for specific use case, and we do allow "alternative" implementations(through the set_bio function), but not through a *_ALT interface.
your example on MBEDTLS_ERR_SSL_WANT_READ and MBEDTLS_ERR_SSL_WANT_WRITE may actually reflect a bug, of a missing dependency, or missing errors. I have raised #2000 to track it.
Description
We are not using mbedTLS's "net" functions, instead we provide our own I/O layer which feeds data to mbedTLS from our C++ in-out streams. (This allows us to run our MbedTlsEngine over any stream - a memory stream for testing, a socket stream, or a thread IPC stream...) I would expect that it is fairly common for users to run mbedTLS over their own I/O abstraction, rather than using the "net" functions to hand raw sockets to mbedTLS.
For those of us using
mbedtls_ssl_set_bio
, we need to choose some return codes to use in ourmbedtls_ssl_send_t
andmbedtls_ssl_recv_t
functions. We are using codes such asMBEDTLS_ERR_NET_RECV_FAILED
, since we have to choose error codes that are allocated from among the mbedTLS numbers (we wouldn't want to return numbers that clash with a future allocation). Those are the natural return codes to be using. mbedTLS does kind-of assume that the return values from the send/receive functions are within its own space of allocated codes, since it checks for specific values from the functions, such as MBEDTLS_ERR_SSL_WANT_READ.Would it be possible to build in the "_NET_" error codes, in error.c, even if MBEDTLS_NET_C is not defined? Otherwise - what codes are you expecting people to return from their
mbedtls_ssl_send_t
andmbedtls_ssl_recv_t
functions? These codes represent a special case; even if customers are not using the "net" layer, the corresponding error numbers are still probably/possibly in use.The text was updated successfully, but these errors were encountered: