I've got an occasional communications failure in a boost asio ssl implementation, the super helpful error message returned by boost is 'asio.ssl:336458004'
I suspect that the numerical figure is some sort of aggregate construct composed of SSL flags, I say that because the linux error codes, the boost asio error codes and the ssl error codes do not have any reference to '336458004', so presumably it must be constructed dynamically.
Can anyone provide some insight into how I should decipher this error code?, Thanks.
they use ERR_PACK from crypto/err/err.h
this will allow converting error to string
#include <crypto/err/err.h>
std::string err = error.message();
if (error.category() == boost::asio::error::get_ssl_category()) {
err = std::string(" (")
+boost::lexical_cast<std::string>(ERR_GET_LIB(error.value()))+","
+boost::lexical_cast<std::string>(ERR_GET_FUNC(error.value()))+","
+boost::lexical_cast<std::string>(ERR_GET_REASON(error.value()))+") "
;
//ERR_PACK /* crypto/err/err.h */
char buf[128];
::ERR_error_string_n(error.value(), buf, sizeof(buf));
err += buf;
}
Probably not included in boost so asio does not need link to ssl when using pure sockets
I eventually gained some insight into the problem by building openssl in debug and putting a breakpoint on the OpenSSL error reporting function ERR_put_error
.
The callstack showed that the problem was originating from SSL_read, caused by the fact that the handshake function had not been initialized. The actual error number used by the ERR_put_error
function is 276, how boost manages to mangle this into 336458004 is beyond me. The bug itself was caused by a a global flag which I was using to toggle the SSL functions as I tunnel through a proxy onto a remote HTTPS server.
Hope this helps someone.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With