Skip to content

Fix: change subscription QoS to 1 in mqtt_demo_basic_tls demo for AWS IoT Core compatibility #1941

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Wilson-LWX
Copy link

Problem:

The mqtt_demo_basic_tls demo sets subscription QoS to MQTTQoS2 by default, which is not supported by AWS IoT Core.
Attempting to subscribe with QoS2 causes the TLS session to close, resulting in SSL_read failed.
The same error happened for publishing if using QoS2.

debug log:
[INFO] [DEMO] [mqtt_demo_basic_tls.c:573] Establishing a TLS session to afi154mel0eud-ats.iot.us-east-1.amazonaws.com:8883.
[INFO] [MQTT] [core_mqtt.c:2999] MQTT connection established with the broker.
[INFO] [DEMO] [mqtt_demo_basic_tls.c:1059] MQTT connection successfully established with broker.

[INFO] [DEMO] [mqtt_demo_basic_tls.c:1575] A clean MQTT connection is established. Cleaning up all the stored outgoing publishes.

[INFO] [DEMO] [mqtt_demo_basic_tls.c:1310] Subscribing to the MQTT topic sdk/test/python.
[INFO] [DEMO] [mqtt_demo_basic_tls.c:1127] SUBSCRIBE sent for topic sdk/test/python to broker.

[ERROR] [Transport_OpenSSL_Sockets] [openssl_posix.c:850] Failed to receive data over network: SSL_read failed: ErrorStatus=EVP lib.
[ERROR] [MQTT] [core_mqtt.c:1803] Call to receiveSingleIteration failed. Status=MQTTRecvFailed
[ERROR] [DEMO] [mqtt_demo_basic_tls.c:1456] MQTT_ProcessLoop failed to receive ACK packet: Expected ACK Packet ID=01, LoopDuration=486, Status=MQTTRecvFailed
[INFO] [DEMO] [mqtt_demo_basic_tls.c:1399] Disconnecting the MQTT connection with afi154mel0eud-ats.iot.us-east-1.amazonaws.com.
[INFO] [MQTT] [core_mqtt.c:3404] Disconnected from the broker.
[ERROR] [MQTT] [core_mqtt.c:3411] MQTT Connection Disconnected Successfully
[INFO] [DEMO] [mqtt_demo_basic_tls.c:1595] Short delay before starting the next iteration ....

Fix:

Changed the subscription QoS to MQTTQoS1, which works correctly with AWS IoT Core.

Tested on:

  • STM32MP157 with Buildroot Linux

This fix ensures out-of-box demo compatibility with AWS IoT Core.

@DakshitBabbar
Copy link
Member

Hey @Wilson-LWX,

This particular demo is a basic TLS demo. It only does server authentication and no mutual authentication. Hence, when connecting with AWS IoT Core, regardless of what QoS is being used, the expected behaviour of this demo is a failed TLS Handshake. This is because AWS IoT Core requires mutual authentication with device certificates. See AWS documentation for device communication protocols.

I would request you to please verify if the behaviour you reported is what actually happened, as it is not in line with the expected behaviour.

Thanks.

@kstribrnAmzn
Copy link
Member

kstribrnAmzn commented May 2, 2025

The current idea of this demo is to build up to an overall demo which works with IoT core (plaintext, then basic auth, then mutual auth). This additive approach is meant to make it easier to connect to IoT Core by building up knowledge.

Still - I don't love this because 1 - our READMEs don't explain this and 2 - is unintuitive when you're looking at an AWS prefixed repo. It's fair to assume a demo would work with the AWS cloud. I am going to start a discussion with the team around how we can correct this. Your thoughts are appreciated here as many of us may be biased by experience with this repo.

@Wilson-LWX
Copy link
Author

Hi DakshitBabbar and KstribrnAmzn,

Thank you for your quick responses.

The mutual TLS authentication steps completed successfully without Qos change(I added client cert and key), as confirmed by the log:
[INFO] [DEMO] [mqtt_demo_basic_tls.c:573] Establishing a TLS session to afi154mel0eud-ats.iot.us-east-1.amazonaws.com:8883.
[INFO] [MQTT] [core_mqtt.c:2999] MQTT connection established with the broker.
[INFO] [DEMO] [mqtt_demo_basic_tls.c:1059] MQTT connection successfully established with broker.

After changing the QoS level from 2 to 1, the publish/subscribe messaging loop works correctly, and I can successfully send and receive messages like "Hello World!":
[INFO] [MQTT] [core_mqtt.c:1476] State record updated. New state=MQTTPubAckSend.
[INFO] [DEMO] [mqtt_demo_basic_tls.c:780] Incoming QOS : 1.
[INFO] [DEMO] [mqtt_demo_basic_tls.c:795] Incoming Publish Topic Name: sdk/test/python matches subscribed topic.
Incoming Publish message Packet Id is 1.
Incoming Publish Message : Hello World!.

Otherwise I cannot get PUBACK and SUBACK properly but error log outputing as "SSL_read failed: ErrorStatus=EVP lib".

This confirms that the demo functions as expected when using QoS 1.

However, it’s worth noting that the demo code originally used QoS 2, which is not supported by AWS IoT Core. This leads to SSL/TLS read failures during the MQTT exchange phase. It's somewhat misleading that an official AWS IoT SDK demo defaults to a QoS level that is incompatible with the AWS IoT Core service.

Changing the default QoS from MQTTQoS2 to MQTTQoS1 ensures out-of-the-box compatibility with AWS IoT Core and avoids connection or message delivery failures.

@DakshitBabbar
Copy link
Member

As @kstribrnAmzn explained, the plain text and basic TLS demos are not designed to work with AWS IoT out-of-the-box, as by default AWS IoT requires mutual authentication. Please use the mqtt_demo_mutual_auth demo to connect to AWS IoT. If you want to use plain text or basic TLS demos with AWS IoT, you will need to setup custom auth. We will update our documentation to clearly highlight this requirement.

That said, we should keep the basic TLS demo code as it is and not update the QoS. Let us know if there are any concerns regarding this.

Thanks.

@Wilson-LWX
Copy link
Author

If mqtt_demo_basic_tls is not intended for AWS IoT Core, then keeping the current implementation makes sense.
However, if the demo is meant to be more generally compatible, I believe using a QoS level that works across a wider range of brokers would be a better design choice.

Thanks for the clarification!

@DakshitBabbar
Copy link
Member

Hi,
As discussed, we are keeping the current implementation, so we’ll be closing this PR.
Appreciate your efforts!
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants