Long wait on MQTT Connect

[sblancodiez]

Hello,

I am playing with Amazon FreeRTOS and when I connect to the broker I observe a delay equal to the timeout value (something like 12 or 14 seconds) before the ACK is processed.

I think the problem is that after sending the connection message the prvManageConnections function does not get anything in the socket read and then sets the next timeout to the full timeout. I think it should check the socket often before waiting for the full time.

Maybe it is a naive fix but I changed in MQTT_Periodic the following:

/* If this Tx operation has not timed out yet, update when the next earliest timeout will happen. */
ulNextTimeoutTicks = mqttMIN( ulNextTimeoutTicks, mqttbufferGET_PACKET_TIMEOUT_TICKS( xBuffer ) );

to the following (including the FreeRTOS header):

/* If this Tx operation has not timed out yet, update when the next earliest timeout will happen. */
ulNextTimeoutTicks = mqttMIN( ulNextTimeoutTicks, 300 / portTICK_PERIOD_MS );

This way, it will check every 300ms for data in the socket instead of waiting.

Is this correct?

[RichardBarry]

Hi - thanks for the information. We will have a look and report back. Which chip/board are you using?

[sblancodiez]

Hi,

Custom board with an Infineon XMC4500, ethernet connection.

[alexa-noxon]

Thanks for the update.

Are you using v1.0.1 of aws_mqtt_agent.c/aws_mqtt_lib.c? v1.0.1 is the most recent and was uploaded about a week and a half ago. You can find the file version at the top of the file above the license agreement.

Have you ported configPRINTF? If so, could you share the log outputs?

[dcgaws]

sblancodiez, happy new year! The behavior you're describing also reminds me of a common gotcha that occurs when your device has an otherwise valid AWS IoT credential, but the associated policy in the AWS IoT "Thing" registry is incorrect or incomplete. The resulting behavior in that case is that the device will connect TCP, negotiate TLS, but then immediately be disconnected by the server. Essentially, the authentication succeeds, but the subsequent authorization check fails.

If that sounds like possibly what you're observing, can you please review this forum thread? In summary, that thread describes how to use the AWS CLI to double-check "Thing" credential and policy configuration.

[sblancodiez]

Hi,

Right now I can't run it for logging, I will do that when possible.

I used both 1.0.0 and 1.0.1 with the same results. The issue is that if when the MQTT task does the first non-blocking recv it does not get data, it sleeps the full timeout value before trying recv again. Since the first recv is called very fast after sending the connect command, and it has a long timeout, you get a very long and not needed wait.

I am not using AWS, I am testing against a Mosquitto broker in my local network. Also, I am not using the demo exactly as is; I am using TLS so obviously there is a parameter change in the setup part.

Best regards,

[dcgaws]

Hello, here's an example of how I tested my own instance of Mosquitto running on the internet. I tested the connection using the Mosquitto pub/sub command-line applications in order to confirm basic routing and connectivity. Then I transferred those settings to my Amazon FreeRTOS device.

Start by running the server. I'm using the Windows version and requiring TLS. However, unlike the AWS IoT broker, I'm not requiring TLS certificate client authentication.

mosquitto.exe -p 443 -v

From the same network that the device is on (i.e., if other than where your server is running), start a subscriber:

mosquitto_sub.exe -h xyz.us-west-2.compute.amazonaws.com -p 443 -q 0 -t string/StringTopic

Next, publish a message on the same topic from a different client command window:

mosquitto_pub.exe -h xyz.us-west-2.compute.amazonaws.com -p 443 -q 0 -t string/StringTopic -m hi

Confirm that the message you published is received by your subscriber instance and printed to its console output.

Once that's working, transfer the settings to the appropriate code locations in your Amazon FreeRTOS project. For example, the DNS name (or IP address) of your MQTT broker should be assigned to clientcredentialMQTT_BROKER_ENDPOINT in aws_clientcredential.h. In that same file, the port number that your MQTT broker is listening on should be assigned to clientcredentialMQTT_BROKER_PORT.

In aws_hello_world.c, ensure that echoCLIENT_ID is unique to your environment. That is, no two MQTT clients should be using the same ID.

Ensure that the sixth parameter of your MQTTAgentConnectParams_t is set to pdTRUE if you successfully tested your broker using TLS. Set that field to pdFALSE if you successfully tested your broker with TCP/IP without TLS.

Likewise, if you are using TLS, the last two parameters of MQTTAgentConnectParams_t must be your encoded server certificate and its size, respectively. By default, when using TLS, our client libraries enforce server certificate trust verification.

[sblancodiez]

Yes, all that was already accounted for and it is working. The issue and possible solution is slow connection because how timeouts are managed. Since I did not write the library I just wanted to share that and ask if there is a negative consequence on the change I proposed, but without change it works although I get around 12 seconds of wait in the connect phase and with my change I get no appreciable wait (300ms as written).

[aggarg]

In order to ensure that the MQTT agent wakes up frequently to check if any data is received on the connected socket, you should define the macro mqttconfigMQTT_TASK_MAX_BLOCK_TICKS (in aws_mqtt_agent_config.h) to a smaller value. Note that the frequent wake up of the MQTT agent to check the received data on the connected socket can be avoided if the board has a capability to inform the MCU (probably some interrupt) about the data received on a connected socket.