mqttsn_client_search_gateway never calls it's callback function, stays busy even after the supposed timeout.

[kwigulaker]

Hello again!

I have configured and initialised the Thread API from the Thread/Zigbee client publisher example, and receive no errors or warnings when attempting to send mqttsn_client_search_gateway. However the MQTT function simply stays busy for the remainder of the run, and I cannot figure out what is wrong. I have run the thread example normally on the board and it works fine. If I am able to call search_gateway, does that mean the thread and mqtt client are setup correctly? Below are some pictures of how I am currently calling the function. The goal of the code is to automatically search and connect to the broker that I have running on a raspberry pi, which I have verified works with the original example.

I have the initialisation done in main.c, while the thread_process is run in it's own FreeRTOS task, in thread_server.c.

I initiate and call the search gateway function in another FreeRTOS task called MainComTask.c and it simply never returns to it's callback function.

I've attempted moving logic around to try and contain everything within one task however I always get the same results. Here is the entire project below:Thread Example (FREERTOS + GATEWAY ISSUE).zip

The Segger file is in Thread Example\examples\thread\mqttsn_client_publisher\pca10056\blank\ses

[Jørgen Holmefjord]

Hi,

Can you provide a sniffer trace of the communication in the Thread network when you call search_gateway? This will send the request to the given (multicast) address, but there might not be any nodes responding at the address.

Have you setup the border router and MQTT-SN gateway using the Raspberry Pi image provided by Nordic?

Did you change any network parameters for the Thread network, or commissioned the nodes into a new network? Specifically the Mesh-Local Prefix address affects the address used by the MQTT-SN examples.

Best regards,
Jørgen

[kwigulaker]

I have setup the border router and gateway using the Nordic raspberry pi image, I do not have an extra dongle or DK to use for the sniffer, as far as I know no network parameters have been changed in the Thread network. Like I mentioned, if I only use the original mqtt_client_publisher example it all works fine, then I am able to find the gateway and publish messages.

[Jørgen Holmefjord]

Hi,

I would highly recommend getting a dongle (or preferably two), to run the sniffer and/or a CLI application. This is an invaluable debug tool when developing your applications.

I tried running your application and perform a sniffer trace, but Wireshark reports that it can't decrypt the frame. This indicates that the key is changed from the default key used by the examples (I have verified that frames from the MQTT-SN publisher example from the SDK can be decrypted). Tried printing the masterkey from your project, and it looks correct, but there might be set/corrupted by something in the application.

Have you verified that the MQTT-SN node and the border router have joined the same network?

Best regards,
Jørgen

[kwigulaker]

What Ive noticed is that the thread instance state on the device that does not return search_gateway is 4, while the other device is 2. From what ive seen this means that this device is a router and not a child like the other device, any idea how I can change the role to a child manually?

[Jørgen Holmefjord]

Role 4 actually means OT_DEVICE_ROLE_LEADER, which is another indication that the device have not joined the same network as the border router. If this device is the only device in the network/partition (with router capabilities), the device will automatically become leader. There is an API, otThreadBecomeChild(), that can be used to change the device role to child (note that this should only be used for testing purposes), or you can call otThreadSetRouterEligible() to disable the router capabilities of the device. Note that if the device is not able to join another network, it will not work without router capabilities.