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

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

Jørgen Holmefjord — Mon, 19 Dec 2022 13:10:24 GMT

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.

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

kwigulaker — Sun, 18 Dec 2022 20:06:13 GMT

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?

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

Jørgen Holmefjord — Fri, 16 Dec 2022 16:40:37 GMT

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

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

kwigulaker — Thu, 15 Dec 2022 18:12:17 GMT

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.

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

Jørgen Holmefjord — Wed, 14 Dec 2022 13:21:11 GMT

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