Hello:
I have successfully gotten the WolfMQTT Azure example working in Windows with some custom network hardware (an embedded Cell modem). I am in the process of porting to my embedded platform and ran into a issue in the MQTT state machine when subscribing to messages from the IOT Hub.
On my embedded platform, WolfSSL/WolfCrypt is compiling OK and all the unit tests are passing.
I can monitor debug strings from both the windows and embedded version and noted 3 differences that cannot I find the source of:
1.) Once the MQTT state machine successfully makes a TCP connection, I get a debug message that the TLS setup has been initiated:
MQTT TLS Setup (1)
At this point, WolfSSL sends out a “hello” message
a.) On my Windows version, I can see the Netwrite function (mqttnet.c) send a 170 byte packet.
b.) On the embedded build, the netwrite function sends 146 bytes.
What would cause this difference? [ (My WofSSL settings for each platform are at the bottom this message).
2.) After the hello packet is sent, I get the TLS Verify call backs
a.) Windows:
MQTT TLS Verify Callback: PreVerify 0, Error 0 (none)
Subject's domain name is (null)
MQTT TLS Verify Callback: PreVerify 0, Error 0 (none)
Subject's domain name is (null)
b.)
MQTT TLS Verify Callback: PreVerify 0, Error -188 (ASN no signer error to confirm failure)
Subject's domain name is Microsoft IT TLS CA 1
Allowing cert anyways
MQTT TLS Verify Callback: PreVerify 0, Error -188 (ASN no signer error to confirm failure)
What would cause the Windows version to not get the domain name? The difference here seems to be important.
3.) At this point I can see of transmit receive activity the is the same between both platforms. There is a point where I get a debug message saying the MQTT connection is successful:
a.) Windows
MQTT Connect: Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
c.) Embedded
MQTT Connect: Success (0)
MQTT Connect Ack: Return Code 5, Session Present 0
Notice the difference in return code. I could not determine what a “5” means in this context.
When the state machine tries to subscribe to messages coming back from the IOT hub, the embedded version hangs waiting for a response. I think there is something going on in #1 and #2 but can’t figure out what to instrument next.
Do you have any ideas on what I can try to debug? It seems that there may be some compile option that is different between the 2 platforms.
Windows WolfSSL Config
#define OPENSSL_EXTRA
#define WOLFSSL_RIPEMD
#define WOLFSSL_SHA512
#define NO_PSK
#define HAVE_EXTENDED_MASTER
#define WOLFSSL_SNIFFER
#define HAVE_TLS_EXTENSIONS
#define HAVE_SECURE_RENEGOTIATION
#define DEBUG_WOLFSSL
#define HAVE_AESGCM
#define WOLFSSL_SHA384
#define WOLFSSL_SHA512
#define HAVE_SUPPORTED_CURVES
#define HAVE_TLS_EXTENSIONS
#define HAVE_ECC
#define ECC_SHAMIR
#define ECC_TIMING_RESISTANT
Embedded WolfSSL config
#define WOLFSSL_NRF51
#define WOLFSSL_USER_IO
#define DEBUG_WOLFSSL
#define SIZEOF_LONG 4
#define SIZEOF_LONG_LONG 8
#define NO_DEV_RANDOM
#define NO_FILESYSTEM
#define NO_MAIN_DRIVER
#define NO_WRITEV
#define NO_FILESYSTEM
#define HAVE_ECC
#define ECC_SHAMIR
#define ECC_TIMING_RESISTANT
#define HAVE_TLS_EXTENSIONS
#define HAVE_SECURE_RENEGOTIATION
#define HAVE_AESGCM
#define HAVE_SUPPORTED_CURVES
#define HAVE_TLS_EXTENSIONS
#define HAVE_EXTENDED_MASTER
#define USE_FAST_MATH
#define USE_WOLFSSL_MEMORY
/* Enables blinding mode, to prevent timing attacks */
#define WC_RSA_BLINDING
#define SINGLE_THREADED
#define WOLFSSL_SHA384
#define WOLFSSL_SHA512
#define WOLFSSL_RIPEMD
#define WOLFSSL_SHA512
#define WOLFSSL_USER_IO
#define WOLFSSL_BASE64_ENCODE
#define ECC_SHAMIR
#define ECC_TIMING_RESISTANT
#define SINGLE_THREADED
#if !defined(USE_CERT_BUFFERS_2048) && !defined(USE_CERT_BUFFERS_4096)
#define USE_CERT_BUFFERS_1024
#endif
#define BENCH_EMBEDDED