W5500 MQTT and TLS

Question

I’m trying to setup a secure MQTT connection using a W5500 and I’m having some problems. The MQTT client works perfectly using an unsecure connection, but as soon as I try to connect over TLS, it looks like I don’t receive any data at all from the broker after the connection is established and my MQTT connection is closed by the broker after the keepalive timer (I don’t receive the ping from the broker so I can’t reply to the keepalive request). Messages sent from the broker also don’t come in. What confuses me is that the TLS handshake is successful so this means that the module actually receives data but it looks like when the TLS connection is established, the data stops coming in. The connection to the MQTT broker is also successful as I can send messages while the connection is active (and I receive those messages on MQTT explorer on my PC so I’m sure it works). To enable TLS on the W5500, I followed the example I found on GitHub GitHub - WIZnet-ioLibrary/W5x00-TLS: The TLS Example for W5X00 using ioLibrary The TLS Example for W5X00 using ioLibrary. Contribute to WIZnet-ioLibrary/W5x00-TLS development by creating an account on GitHub. But I’m clearly missing something and I can’t find what it is. I’m using an STM32F429ZI MCU with a WIZ850io module. I’m working on STM32CubeIDE (eclipse). Does anyone have a complete W5500 MQTT + TLS example they don’t mind to share? Any help would be greatly appreciated. Thanks.

Eugeny · Answer

Where broker is running - on the PC? First I would confirm that secure channel (socket) is actually being set up successfully, for this you can use Wireshark running on the broker side. It would help to analyze the whole packet exchange to see what is wrong. Sevinz: The connection to the MQTT broker is also successful as I can send messages while the connection is active This is confusing. Are you talking about unsecure connection? Or you connect to broker with PC and this connection is successful?

Sevinz · Answer

Broker is paid hosting at cloudmqtt, using mosquitto 1.5.7. I’ll setup a local broker and see if I get different results. I will also install wireshark to get some readings because all I have right now is a serial debug terminal. Some clarifications: When using an unsecure connection (port 1883), I have no problem at all. My IoT device can send and receive messages to/from the broker and the connection doesn’t drop. It works as expected. When I use a secure connection on port 8883: My PC can connect to the mqtt broker using TLS so my certificates are setup properly. My IoT device can open a connection to the broker using TLS. When I run the wiz_tls_connect() from the github example, I receive the following debug message: init connect[1] . Performing the SSL/TLS handshake... => handshake And then I get about 300 lines of debug messages about the ongoing handshake process, the exchange of keys, random numbers, etc and it ends like so: <= handshake wrapup <= handshake ok [ Ciphersuite is TLS-RSA-WITH-AES-256-CBC-SHA256 ] Connected to Socket 0 I can post the entire debug message if it’s useful, but all I read seems normal, I get no error messages up to this point After that I get to run MQTTConnect() and that’s where it fails. My debug messages show some data is being sent and received (about 40 lines of debug messages, no error messages), and after 5 seconds I get: MQTTConnect() returned: 255 Connection closed The CONNACK is never received and MQTTConnect() times out and returns 255. At this point I only have server side certificates enabled. My broker doesn’t require clients to use certificates. I’ve read I can still use username and password to login to the mqtt broker while using server certificates only for authentication. My connectData structure uses the same ID, username and password as my unsecure connection. Is this why it fails? Because on my broker I get the following messages in the log: 2022-10-05 12:15:09: New connection from ***.***.***.*** on port…

Sevinz · Answer

The broker runs mosquitto 1.5.7, I’m not using mosquitto source codes in my client For the client I’m using the paho mqtt port included in the iolibrary driver from wiznet. I did some more debugging and I think I found where this is coming from. in MQTTConnect(): if (waitfor(c, CONNACK, &connect_timer) == CONNACK) // This is true so CONNACK is received { unsigned char connack_rc = 255; unsigned char sessionPresent = 0; if (MQTTDeserialize_connack(&sessionPresent, &connack_rc, c->readbuf, c->readbuf_size) == 1) // This returns 1 (success) rc = connack_rc; // <--- Why is connack_rc not changed in MQTTDeserialize_connack ? else rc = FAILURE; } else rc = FAILURE; exit: if (rc == SUCCESS) c->isconnected = 1; return rc; MQTTDeserialize_connack returns 1 (success), so rc = connack_cr, but connack_rc which is passed to MQTTDeserialize_connack is left untouched and keeps its initialized value of 255 which is the returned value. So that’s where the 255 comes from. int MQTTDeserialize_connack(unsigned char* sessionPresent, unsigned char* connack_rc, unsigned char* buf, int buflen) { MQTTHeader header = {0}; unsigned char* curdata = buf; unsigned char* enddata = NULL; int rc = 0; int mylen; MQTTConnackFlags flags = {0}; FUNC_ENTRY; header.byte = readChar(&curdata); if (header.bits.type != CONNACK) // header.bits.type is equal to CONNACK this is OK goto exit; curdata += (rc = MQTTPacket_decodeBuf(curdata, &mylen)); // rc == 1, mylen == 0 enddata = curdata + mylen; if (enddata - curdata < 2) // mylen == 0 so this evaluates to true and exits goto exit; flags.all = readChar(&curdata); *sessionPresent = flags.bits.sessionpresent; *connack_rc = readChar(&curdata); // <--- never happens so connack_rc is left unchanged rc = 1; exit: FUNC_EXIT_RC(rc); return rc; } The variable mylen is at 0 after MQTTPacket_decodeBuf() returns. So enddata is equal to curdata and the function exits. The code where connack_rc is assigned never gets executed. When MQTTDeserialize_connack is called…

Sevinz · Answer

I went and checked the most recent paho mqtt code and on their version the value of connack_rc is initialized at 0 (connack_rc is changed to data->rc but it serves the same purpose). The code from paho mqtt embedded_c / MQTTConnect() : if (waitfor(c, CONNACK, &connect_timer) == CONNACK) { data->rc = 0; data->sessionPresent = 0; if (MQTTDeserialize_connack(&data->sessionPresent, &data->rc, c->readbuf, c->readbuf_size) == 1) rc = data->rc; else rc = FAILURE; } else rc = FAILURE; exit: if (rc == SUCCESS) { c->isconnected = 1; c->ping_outstanding = 0; } #if defined(MQTT_TASK) MutexUnlock(&c->mutex); #endif return rc; So I changed it in my code to initialize connack_rc = 0 and voilà, everything works fine, well sort of. I can now connect to mqtt broker and keep the connection up, I can send messages from the IoT device and I receive those messages on my PC and I’m not disconnected after the keepalive timer. The only thing not working at the moment is subscribe. MQTTSubscribe() returns -1 (failure) but the broker receives the subscribe message as it tries to send messages to my IoT device (I see data coming in on my debug). I still got some debugging work to do. I also want to check the effects of these changes on the unsecure connection. I’ll keep updating this post as it may be helpful to someone else here and I will submit a bugfix to the ioLibrary github when everything works fine. Thanks for your support! Sometimes just talking about your problem rewires your brain and you find the answer! I didn’t know about Cedalo, thanks for the tip, I’ll keep it in my bookmarks for future reference.

joel · Answer

i followed the above mentioned procedure and was able to communicate both with the mosquitto and aws iot however the MQTTYield was not working it was stuck in a loop trying to read so i did a small fix and it worked like charm Capture-min1253×202 7.55 KB

Rene · Answer

Hi Sevinz, I’m working on a similar solution, but I need to send data to AWS. Have you connected to AWS, or are you using another broker?

Rene · Answer

Hi Joel, Could you show me how you set the AWS parameters in the code? This includes the AWS endpoint, client ID, client certificate, CA certificate, and private key. Thanks!

Sevinz · Answer

I have not tried AWS, I’m just using a basic “cloud compute” instance running linux. I am hosting my own mosquitto broker on it, along with a web app and a database. MQTT is secured through mbedtls, using self signed certificates for mutual client / server authentication. Been working like a charm for almost a year.

joel · Answer

Capture21012×258 18.1 KB joel: use the wiznet tls example and edit according to these images Hope this works you can ask me further after following these steps

Rene · Answer

Thanks for your reply, Sevinz, and Joel. Joel, I followed the steps and I loaded the certificates, but I am unable to connect. I got a time-out error from the connect function. Please see the log below. I got the network log, and the module tried to connect using the IP instead of the endpoint. image796×121 8.84 KB image1042×248 13.5 KB I was just wondering, do I need to use DNS to obtain the IP from the endpoint, or does the library handle this internally? How did you do this? Also, do you know where to configure the ClientID in the code? I need to publish data with a specific client ID. Thank you! Rene.

Sevinz · Answer

I remember having a similar problem where the handshake would terminate abnormally. The example I was using had these 2 functions in SSLInterface.c: /*Shell for mbedtls recv function*/ int WIZnetRecv(void *ctx, unsigned char *buf, unsigned int len ) { int32_t ret; ret = recv(*((int *)ctx),buf,len); return ret; } /*Shell for mbedtls send function*/ int WIZnetSend(void *ctx, const unsigned char *buf, unsigned int len ) { return (send(*((int *)ctx),buf,len)); } For this example to work with my project, I had to modify these 2 functions to avoid getting handshake failures. I’m not sure if this is only a problem with connecting to mosquitto and the way the handshakes are handled, I didn’t have time to do more testing. IIRC the recv() function returns 0 if the buffer is empty which basically tells mbedtls “success, there is no more data to receive” and this results in an invalid SSL record among other things. Same thing for the send() function. Don’t take my word for it though and test it yourself to be sure! So I had to avoid returning a 0 and instead return an error code mbedtls is expecting. I modified those 2 functions like so: int WIZnetRecv(void *ctx, unsigned char *buf, unsigned int len) { int32_t ret = 0; if(getSn_RX_RSR(*((int *)ctx)) == 0) return MBEDTLS_ERR_SSL_WANT_READ; ret = recv(*((int *)ctx),buf,len); return ret; } /*Shell for mbedtls send function*/ int WIZnetSend(void *ctx, const unsigned char *buf, unsigned int len) { int32_t ret = 0; ret = send(*((int *)ctx),buf,len); if(ret == 0) return MBEDTLS_ERR_SSL_WANT_WRITE; return ret; } For the receiving part, this will first check if the buffer is empty and if so, return the correct mbedtls error code instead of 0. If there’s data in the W5500 buffer, recv() is called normally and the number of received bytes is returned. For the sending part, this is pretty much self explanatory. Like I said I didn’t have time to push the tests so I don’t know if this error is “generalized” or if it just applies to my…

Rene · Answer

Thank you, Sevinz, for your reply. I decided to use the “aws-iot-device-sdk-embedded-C”, and it worked well. I found an example with W5500 + AWS SDK + mbedTLS, which I ported to my project. Thank you for your help.

alien · Answer

Hi Rene! Tell me, please, where did you find an example with W5500 + AWS SDK + mbedTLS? Is this somewhere on Github? Thank’s!

Rene · Answer

Hi Alien, Check the link to the GitHub https://github.com/scarletwiz/W5300-AWS-C.git Regards.