MQTT CLient unable to connect to AWS broker

Hi rsala. The IoT logs in CloudWatch won't start recording anything until after you get the MQTT connection. These are all the event types: https://docs.aws.amazon.com/iot/latest/developerguide/cwl-format.html

Please follow the troubleshooting here: https://docs.aws.amazon.com/iot/latest/developerguide/diagnosing-connectivity-issues.html.

I don't know if this helps or not but my #1 issue when I connect to IoT core then immediately get disconnected is permissions. When it happens to me, it's usually because as soon as I get an onConnect callback I try to send a Subscribe. If the policy doesn't allow me to subscribe to that thing (I have it pretty locked down) it just summarily and disconnects in response to the unlawful request. That request is usually either a SEND or SUBSCRIBE that the client should not have made.

From the sound of it, your connection may not even be getting that far ... but permissions still could be the problem. Make sure whatever certificate you are using is active, and make sure it is attached to a policy that includes the iot:Connect action.

Not sure if I'm steering you in the wrong direction, apologies if I am, but whenever I have had "immediately disconnects" problems it has always been related to permissions.

Thank you to both Greg_B and wz2b. Their thoughtful replies gave me plenty to investigate.

I worked my way through the troubleshooting guide that Greg_B linked to but unfortunately, nothing seemed to help with my particular problem. My certificates all check out using openssl s_client, the json sdk code and I can even use them to successfully publish to the IoT broker with mosquitto_pub.

Furthermore, a Wireshark capture seems to indicate that the TLS handshake is successful and it is only when my client attempts to connect that I receive an encrypted alert, which I assume to be a TLS close_notify, because I receive a TCP FIN shortly afterwards:

Time,Source,Destination,Protocol,Length,Info

0,10.0.0.11,54.156.47.148,TLSv1.2,336,Client Hello

0.016360719,54.156.47.148,10.0.0.11,TLSv1.2,150,Server Hello

0.001577507,54.156.47.148,10.0.0.11,TLSv1.2,685,Certificate

0.00001705,54.156.47.148,10.0.0.11,TLSv1.2,438,"Server Key Exchange, Certificate Request, Server Hello Done"

2.518046294,10.0.0.11,54.156.47.148,TLSv1.2,1329,"Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message"

0.015707564,54.156.47.148,10.0.0.11,TLSv1.2,60,Change Cipher Spec

0.000007277,54.156.47.148,10.0.0.11,TLSv1.2,99,Encrypted Handshake Message

0.001473909,10.0.0.11,54.156.47.148,TLSv1.2,193,Application Data

0.022366332,54.156.47.148,10.0.0.11,TLSv1.2,85,Encrypted Alert

I've verified in the debugger that the Application Data my client sends on the second to last line is the MQTT connect.

And in response to wz2b cautioning against sending additional publish or subscribe messages too soon after the connect, the timing above shows that the broker sends out the encrypted alert in about 22 ms, well before the client can attempt any further messages.

I also looked into the policy issue wz2b mentioned, and as a proof of concept, I made my policy as restriction free as possible:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:", "Resource": "" } ] }

As I mentioned above, with this policy in place I can connect to the IoT broker and publish any random topic I choose with mosquitto_pub.

To follow is the decrypted disection of the Wireshark capture of the MQTT connect when I successfully connect to my local mosquitto broker using the same client:

MQ Telemetry Transport Protocol, Connect Command

Header Flags: 0x10, Message Type: Connect Command

    0001 .... = Message Type: Connect Command (1)

    .... 0000 = Reserved: 0

Msg Len: 108

Protocol Name Length: 4

Protocol Name: MQTT

Version: MQTT v3.1.1 (4)

Connect Flags: 0x06, QoS Level: At most once delivery (Fire and Forget), Will Flag, Clean Session Flag

    0... .... = User Name Flag: Not set

    .0.. .... = Password Flag: Not set

    ..0. .... = Will Retain: Not set

    ...0 0... = QoS Level: At most once delivery (Fire and Forget) (0)

    .... .1.. = Will Flag: Set

    .... ..1. = Clean Session Flag: Set

    .... ...0 = (Reserved): Not set

Keep Alive: 30

Client ID Length: 23

Client ID: XXXXXX-XXX_XXXXXXXXX_XX

Will Topic Length: 41

Will Topic: XXXXXXX/XXXX/NDEATH/XXXXXXXXXXX_XXXXX_XX/

Will Message Length: 28

Will Message: …

Everything appears to be in order, so I'm really at a loss where to turn next! Is it really the case that the AWS IoT broker has no way of logging failures that do not rise to the level of a connect?