Yes, we are using a pre-shared key cert and public key.
How does using a CA solves this problem?

Hi,

Our company uses a wolfMQTT together with wolfSSL on a pic32 embedded client to communicate with a third party MQTT broker let's call it "domain1".

The pic32 client has "domain1" server certificate planted within the code and wolfSSL_check_domain_name() function is called to authenticate the domain. The connection is secured and is working great.

While the pic32 MQTT clients are being scattered in customer's sites all over the world, it might happen that this third party MQTT broker would not be reliable anymore.

In order to solve this possible problem, we decided to create a middle-way dns record (let's call it "domain2") in our private server that points to the dns of whatever MQTT broker that will be used in the future (currently "domain1" but can be "domain3" in the future) - like a lined list (-: .

Currently we tried changing the wolfMQTT "DEFAULT_MQTT_HOST" from pointing to good old "domain1" to pointing the middle-way DNS record "domain2" and it does not connect. I guess its because the pre-planted server certificate certificate still has "domain1" in it.

The question is: what server certificate (and its domain) is require to pre-plant inside the pic32 MQTT client in order to communicate with every possible domain that will be pointed by "domain2"(i believe this is called dynamic DNS)?

Thanks in advanced,

Gil

Hi,

We use wolfmqtt client on pic32 with TLSv1.2.
In some cases (usually related to internet connection problems) we see the following scenario:
The app state machine rolls into MqttClient_NetConnect():

int rc = MqttClient_NetConnect(&appData.myClient, (const char *)&appData.host,                sds_web_config.comm_setting.mqtt_port.Val, MQTT_DEFAULT_CMD_TIMEOUT_MS, SDS_TLS/*NULL*/, mqtt_sds_tls_cb/*NULL*/);

Since it fails to connect, timeout of 20 seconds sends the state machine to ERROR state:

        case APP_TCPIP_ERROR:
        {
            /*no matter what the issue is, free the tcp/mqtt resources and re-connect
              this will include cases of: cable removal, router disconnects, poor internet connection*/
            

            rc= MqttClient_NetDisconnect(&appData.myClient);

            if (rc== MQTT_CODE_SUCCESS)
            {
                
                   //start all over again including dhcp
                   appData.state = APP_TCPIP_WAIT_INIT; 


                   /* Free resources */
                    if (appData.myClient.tx_buf) WOLFMQTT_FREE(appData.myClient.tx_buf);
                    if (appData.myClient.rx_buf) WOLFMQTT_FREE(appData.myClient.rx_buf);
                    
                    /* Cleanup network */
                    MqttClientNet_DeInit(&appData.myNet); 
              
            }
            
        }
        break;

and goes back to MqttClient_NetConnect() state.

Then after about 20 loops, the MqttClient_NetConnect() function returns NetConnect: Rc=-1, SoErr=111

And from that poin on the MqttClient_NetConnect() function never recovers - therefore when internet connection comes back, state machine gets locked-up in a non-connect state.

In order to bring the mqtt connection back again, we power the board off and then on again

Do you know how can we make the state-machine recover from this lock-up?

Regards,

Gil

Hi Kaleb,

Thanks for your great assistance, i will be out of the office this week, so i will get back to you next week with the following info:

1. I will check which draft is it!
2. I will have a wireshark trace!

Regards,

Fonea Gil

Hi Kaleb,

So now i am trying to verify why this is happening.

I uncommented #define WOLFMQTT_DEBUG_SOCKET and got the following messege:
MqttSocket_TlsConnect Error -1: Num -328

This error means:
BUFFER_ERROR                 = -328,   /* malformed buffer input   */

so i searched to forum and i have found a case that have a simillar phenomena:
https://www.wolfssl.com/forums/topic113 … u1404.html

Well, we are not using ECDH, but still, as you wrote in this ticket:
"If you use a DHE_RSA cipher suite rather than sending back a "Server Hello Done" message at the end of the handshake, that endpoint responds with this plaintext message.

use only10UVeriSign Trust NetworkN0L10    UFR10U
    KEYNECTIS1
0UROOT10UKEYNECTIS ROOT CA

So wolfSSL, which is looking for a TLS packet that is encoded as the SERVER HELLO DONE message, thinks it is a malformed message"

Is there anything i can do to verify this is the case?

Regards,
Gil

Hi,

Our PIC32MZ runs perfectly with wolfMQTT and TLS1.2.

The server is an OPENSSL server that a TLS1.3 support was added to it lately.

Our company wants to move on to TLS1.3.

To do so, i did the following:

1. uncommented:
#define WOLFSSL_TLS13
in user_settings.h file

2. added the following define's to user_settings.h file (otherwise project would not build):

#define WC_RSA_PSS    //gil - added to support TLSv13
#define HAVE_HKDF

3. In the in the TLS certificate and callback verify function:
changed the call from wolfTLSv1_2_client_method() (in wolfSSL_CTX_new) to wolfTLSv1_3_client_method()

Then i have a printout of the logfile:

wolfSSL Entering wolfCrypt_Init
wolfSSL Entering WOLFSSL_CTX_new_ex
wolfSSL Entering wolfSSL_CertManagerNew
wolfSSL Leaving WOLFSSL_CTX_new, return 0
wolfSSL Entering wolfSSL_CTX_set_verify
wolfSSL Entering wolfSSL_CTX_load_verify_buffer
Processing CA PEM file
wolfSSL Entering PemToDer
Adding a CA
wolfSSL Entering GetExplicitVersion
wolfSSL Entering GetSerialNumber
Got Cert Header
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Algo ID
Getting Cert Name
Getting Cert Name
Got Subject Name
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Key
Parsed Past Key
wolfSSL Entering DecodeCertExtensions
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeSubjKeyId
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeAuthKeyId
wolfSSL Entering GetObjectId()
wolfSSL Entering DecodeBasicCaConstraint
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
    Parsed new CA
    Freeing Parsed CA
    Freeing der CA
        OK Freeing der CA
wolfSSL Leaving AddCA, return 0
   Processed a CA
Processed at least one valid CA. Other stuff OK
wolfSSL Entering wolfSSL_CTX_use_certificate_buffer
wolfSSL Entering PemToDer
Checking cert signature type
wolfSSL Entering GetExplicitVersion
wolfSSL Entering GetSerialNumber
Got Cert Header
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Algo ID
Getting Cert Name
Getting Cert Name
Got Subject Name
wolfSSL Entering GetAlgoId
wolfSSL Entering GetObjectId()
Got Key
Not ECDSA cert signature
wolfSSL Entering wolfSSL_CTX_use_PrivateKey_buffer
wolfSSL Entering PemToDer
wolfSSL Entering SSL_new
wolfSSL Leaving SSL_new, return 0
wolfSSL Entering wolfSSL_dtls_set_using_nonblock
wolfSSL_dtls_set_using_nonblock() is DEPRECATED for non-DTLS use.
wolfSSL Entering SSL_connect()
wolfSSL Entering SendTls13ClientHello
Adding signature algorithms extension
Adding supported versions extension
growing output buffer

Key Share extension to write
Supported Versions extension to write
Signature Algorithms extension to write
Supported Groups extension to write
Shrinking output buffer

wolfSSL Leaving SendTls13ClientHello, return 0
connect state: CLIENT_HELLO_SENT
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
wolfSSL error occurred, error = -323
wolfSSL Entering SSL_get_error
wolfSSL Leaving SSL_get_error, return -323
wolfSSL Entering SSL_connect()
growing input buffer

received record layer msg
wolfSSL Entering DoTls13HandShakeMsg()
wolfSSL Entering DoTls13HandShakeMsgType
processing server hello
wolfSSL Entering DoTls13ServerHello
growing output buffer

Shrinking output buffer

wolfSSL Leaving DoTls13HandShakeMsgType(), return -32

Can you please help me understand why error -323 occurs, and what could possibly cause that?

Regards,

Gil

Hi Eric,

Reproduce this problem with any of the other Harmony network examples might require a lot of (currently unavailable) effort and change too many parameters in the code that might eliminate the error effect.

I think i might try consulting with Microchip guys for now.

If that doesn't work i'll get back here.

Thanks.

SOCK_CONNECT() keep returning error 119 - EINPROGRESS upon failure

Thanks

By the way, maybe this info will help:

I discovered that the failing scenario usually happens after letting the MQTT client idle for about twenty minutes.

Idle means connection is ok, no data transfer only KEEP ALIVES are present between server and client. Then (after about 20 minutes) router is powered off and then on.

Thanks,
Gil

Hi Eric,

We already have the fix present.

But i did some more digging and found that on a successful connection function             

rc = SOCK_CONNECT(sock->fd, (struct sockaddr*)&sock->addr, sizeof(sock->addr));

returns -1 for some time until connection is made and then becomes 0.
While in the failing state, SOCK_CONNECT returns -1 forever.

Regards,
Gil

Hi,

I have a question regarding MQTT with PIC32 Harmony v1.08.

My APP state machine connects very well to MQTT broker.

The problem arises when we run a test that network shuts down (router is powered off and then back on again).

Most of the time the APP state machine recovers, but sometimes not.

The sequence being executed is:

1. TCPIP stack Initialization
2. polls on the state that has rc = MqttClientNet_Init(); until rc == MQTT_CODE_SUCCESS and then moves on to the next state.
3. polls on the state that has MqttClient_Init(); until rc == MQTT_CODE_SUCCESS and then moves on to the next state.
4. polls on the state that has MqttClient_NetConnect().

When the system fails, MqttClient_NetConnect() returns rc == MQTT_CODE_CONTINUE forever and never gets MQTT_CODE_SUCCESS.

Is there any race here between physical network connection and attempt to connect to broker?

I need some help. If pieces of code are required i can upload them.

Regards,

Gil

12

(3 replies, posted in wolfSSL)

Hi,

I am using wolfssl ver 3.1.3 and wolfMQTT 1.1.0 with TLSv1.2 on microchip.

Can TLS1.2 run with #define NO_DH being used?

Thanks,

Gil