1 (edited by eli.hughes 2019-01-10 13:59:54)

Topic: Azure Connection - Hang at Subscription to Topic

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

Share

2 (edited by eli.hughes 2019-01-14 17:32:22)

Re: Azure Connection - Hang at Subscription to Topic

I just wanted to post that I have things working on my embedded platform.  There were several issues but I wanted to post some things to help someone else who may be doing something similiar.


1.)   Azure cares about correct time.    I was trying to work around not having unix time but it is needed for the connection string.  I had to write the code to ping a NIST time server.

2.)   The MQTT state machine does not report an error when there is a failed connection in my case I was getting a return code of "5" in the MQTT CONN ACK packet.   This turned out to be an authentication issue.

The root cause of issue was my embedded (sn)printf library not handling long long formatting.   The connection string was malformed.


related:

From #1 & 2 in my original post.

The defines #OPENSSL_EXTRA  and #WOLFSSL_SNIFFER were cause the differences in packet sizes and the (NULL).  They were used in the embedded platform as they seemed to need a lot of OS support.

Share

Re: Azure Connection - Hang at Subscription to Topic

eli.hughes,

Thank you so much for sharing your findings and we apologize for the delayed responses as the whole company was traveling to our annual meeting and back here at the beginning of the year. In the future for best response times please feel free to shoot an email to support@wolfssl.com if you don't see an update in a timely manner here on the forums.

Thanks!

Warm Regards,

- K