MQTT client successfully subscribed but does not see data on subscribed topic

Libraries
1

We are using NXP MCUXpresso IDE for an application running on the i.MX RT1064, and are new to IoT and MQTT. The AWS shadow example firmware provided by NXP has been running fine on our custom board, both publishing and received data on the subscribed topics. The product does not use shadows at the moment, so that example was adapted to publish and subscribe to non-shadow-related topics. The device successfully connects to the AWS MQTT broker, and successfully publishes a topic.

The MQTT library reports that it has successfully subscribed to the desired topic. This topic is published by the AWS side immediately in response to the topic published by the device. This can be observed in the AWS MQTT test client. The issue is that the callback is not invoked, as if the device is not seeing the topic published from AWS at all. There are no errors reported other than a 15-second timeout expiring after the device publishes its topic.

The code that times out is waiting for a notification that the topic data has been received, and this notification would come from the callback, which is not being invoked.

This is the debug output (SHADOW_DEV tag is a remnant of the shadow device code):

6 5037 [MQTT] [INFO] Creating a TLS connection to xxxxxxxxxxxxxx-ats.iot.us-east-1…
7 7258 [MQTT] [INFO] (Network connection 0x20225644) TLS handshake successful.
8 7258 [MQTT] [INFO] (Network connection 0x20225644) Connection to xxxxxxxxxxxxxx-ats.iot.us-east-1… established.
9 7259 [MQTT] [INFO] Creating an MQTT connection to the broker.
10 7456 [MQTT] [INFO] MQTT connection established with the broker.
11 7457 [MQTT] [INFO] Successfully connected to MQTT broker.
12 7457 [SHADOW_DEV] [INFO] MQTT Agent is connected. Initializing shadow device task.
13 7457 [SHADOW_DEV] [INFO] Sending subscribe request to agent for new topics.
14 7535 [SHADOW_DEV] [INFO] Successfully subscribed to topic.
15 7535 [SHADOW_DEV] [INFO] Publishing to /new topic using client token 7535.
16 7535 [SHADOW_DEV] [INFO] Successfully sent a publish message to /get new topic.
17 8285 [MQTT] [INFO] Publishing message to devices/device_id/command/data_list.

18 8339 [MQTT] [INFO] Ack packet deserialized with result: MQTTSuccess.
19 8340 [MQTT] [INFO] State record updated. New state=MQTTPublishDone.
20 22535 [SHADOW_DEV] [ERROR] Timedout waiting for a response for /data_list request.

The string in the topic filter matches the topic being published by the AWS side, and I do not know what else to look at to see why the device does not receive the data. Any guidance on how to track this down would be appreciated, including whether there is a more appropriate forum to post this question.

2

It may be a policy issue. Can you check the AWS policy attached to the device certificate?

3

This is the policy. It seems to include what is needed (?)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iot:Connect"],
      "Resource": [
        "arn:aws:iot:*:*:client/${iot:Connection.Thing.ThingName}"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["iot:Publish", "iot:Receive"],
      "Resource": [
        "arn:aws:iot:*:*:topic/devices/${iot:Connection.Thing.ThingName}/*",
        "arn:aws:iot:*:*:topic/broadcast/from/devices"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["iot:Subscribe", "iot:Receive"],
      "Resource": [
        "arn:aws:iot:*:*:topicfilter/devices/${iot:Connection.Thing.ThingName}/*",
        "arn:aws:iot:*:*:topicfilter/broadcast/to/devices",
        "arn:aws:iot:us-east-1:xxxxxxxxxxxx:topicfilter/iot/game/reply/${iot:Connection.Thing.ThingName}/*"
      ]
    }
  ]
}
4

Just to rule out that it is not a policy issue, can you try the following overly permissive policy:

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

Note that it is only for testing and NEVER DO THIS IN PRODUCTION.

5

We made that change, and the data was received at the device, so it does appear that there is some issue with the policy.

6

Thank you for reporting back. Are you able to fix your policy and resolve the issue?