• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 235 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3135: MQTT Connect ACK timeout handling

Ridha Mastouri
Prodigy 50 points
Part Number: CC3135

Hello, 

I am using the BOOSTXL-CC3135 WIFI module interfaced with an STM32L4 over SPI Bus, which running on FreeRTOS.

I could successfully run the MQTT client v1.1.0 provided by TI (Connect, publish, subscribe ... ).

So timeout protection is a hard requirement for my system, and when I'm debugging the MQTT stack, i found that there is no timeout protection for Connect acknowledge, a semaphore is provided with portMAX_Delay as a waiting time. 

    /* Wait for a CONNACK here */
    MQTTClient_ackRxSignalWait(clientCtx->ackSyncObj);    ( File : mqtt/interface/mqttclient.c    Line : 922 )
What if CONNACK message is not coming from the server or broker side? 
The MQTTClient_connect() APIs gets blocked forever ?

Regards,

Ridha

  • 0
    TI__Guru 61556 points

    I will need to double check this but from initial review it seems that you are right.

    Seems that the semaphore is only released when the ACK is return or upon disconnection.

  • 0
    Prodigy 50 points

    Hello Kobi,

    Thanks a lot for your reply.

    Is there a new version for MQTT Library or a recent patch that fix this issue?

    If not, what about if i apply the listed modifications on the MQTT stack:
    + under the @ref MQTTClient_connect () APIs, the wait for CONNACK message is applied only when blockingSend flag is set to true.
    + under @ref processNotifyAckCB, in case of MQTT_CONNACK message, the Post of CONNACK Signal is applied only when the blockingSend flag is set  to true. In otherwise, a callback is performed to notify the user application

    So, the timeout mechanism for @ref MQTTClient_connect can be triggered by the application via the registered callback function.

    Is there any regression with the listed patch?

    Best regards,
    Ridha

  • +1 in reply to Ridha Mastouri
    TI__Guru 61556 points

    We currently don't have this high in our priority list.

    The source code is free for you to update.

    I'm not sure i understand your fix. Are you suggesting adding the new flag?

    Why not just replacing the sem_wait with sem_timedwait? (+ checking of the return value)

    br,

    Kobi

  • +1 in reply to Kobi Leibovitch
    Prodigy 50 points

    It's the same flag used by the library for subscribe, unsubscribe and publish commands.

    But, sem_timedwait will fix the issue.

    Thank you. 

    Regards,

    Ridha