This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MQTT connection fail while "THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE" - SED

Hi,

I use a pca10056 with the "mqttsn_sleepy_publisher" example. Unfortunately, I cant connect to the mqttsn gateway. It throws me:

"NRF_LOG_ERROR("CONNECT message could not be sent. Error: 0x%x\r\n", err_code);"

I use the standard code for the DK and the border router. I just formed my own thread network and adjusted the credentials (panid ...) within the DK. Connecting and transmitting with radio ON works fine. 

I have found that ticket. So I guess it might has something to do with those values:

#define DEFAULT_CHILD_TIMEOUT    40                                     /**< Thread child timeout [s]. */
#define DEFAULT_POLL_PERIOD      1000                                     /**< Thread Sleepy End Device polling period when MQTT-SN Asleep. [ms] */
#define SHORT_POLL_PERIOD        100                                      /**< Thread Sleepy End Device polling period when MQTT-SN Awake. [ms] */
#define SEARCH_GATEWAY_TIMEOUT   5                                          /**< MQTT-SN Gateway discovery procedure timeout in [s]. */                                   

Do you have any idea, whether those values need to change? I know what they should do, but changing them didnt help much. 

Ps: I use Linux, SDK17, VS-Code, pca10056

Parents
  • Hi

    Are you using the exact same configurations for the border router and MQTT-SN gateway as we use in out border router image? Have you tested the provided border router image to see if the examples works correctly with this? Please make sure to follow the instructions in Testing closely.

    If possible, can you upload a sniffer trace showing on-air communication between the devices? Please check out the nRF Sniffer for 802.15.4 for example that can be used to capture packetrs transmitted on protocols based on IEEE 802.15.4, like Thread for instance.

    Best regards,

    Simon

  • Hi Simonr,

    thanks a lot for your answer. I tested the setting with a freshly flashed border router and DK with standard software and it still doesn't work. But when I reflashed the border router I came across a change I made (found it in my notes 6 month ago) after the flash. 6 month ago, I had the same problem with the mqttsn gateway, but with a normal enddevice (not sleepy enddevice). I used the example "mqttsn_client_publisher". The solution was to change the "GatewayUDP6Broadcast" address in /etc/paho-mqtt-sn-gateway.conf to "ff03::1" fitting the address in the SDK. After restarting the gateway, everything worked fine. Now, I thought maybe that is the problem, so I changed it back to the original one "ff33:40:fdde:ad00:beef:0:0:1", but it didn't work neither. Do you think it has something to do with that address because the discription inside the conf says:

    # GatewayUDP6Broadcast address is set to all Thread devices address
    # in order to enable Thread Sleepy Devices to receive multicast messages
    # sent from the gateway.

    Greetings

    Maboo

  • Hello Maboo,

    I'll handle this ticket, since Carl Richard is currently out of office. 

    Maboo said:
    Where can I change the MeshLocalPrefix?

    I am not sure you can change this, or if it is just given when the network forms. Is there a particular reason why you want to change this?

    Maboo said:
    1. What is the difference between the MeshLocalPrefix and the OnMeshPrefix?

    Where did you find "OnMeshPrefix"? A quick search on the openthread - get started guide didn't give any search results. Perhaps you can show me where you found it?

    Maboo said:
    Could you recommend a website/tutorial just to better understand the network parameters? (Open Thread website was a good start, but it doesn't goes that deep)

    I am not aware of any other guides that go that much deeper. I guess you can check with Open Thread's website and forums. 

    Best regards,

    Edvin

  • Hi Edvin,

    thanks for taking over. Basically I struggling with the answer from Carl Richard.

    You must change the address to match the network prefix

    What address? Does he mean the "GatewayUDP6Broadcast" address in /etc/paho-mqtt-sn-gateway.conf. And how do I form/change the address to match the network prefix? (==mesh local prefix???).

    I found this on Open Thread webpage:

    You might notice that Sleepy End Devices (SEDs) are not included as a recipient in the multicast table above. Instead, Thread defines link-local and realm-local scope unicast prefix-based IPv6 multicast address used for All Thread Nodes, including SEDs. These multicast addresses vary by Thread network, because it is built on the unicast Mesh-Local prefix (see RFC 3306 for more details on unicast-prefix-based IPv6 multicast addresses).

    But the explanations on the RFC 3306 webside are too confusing for me.

    The problem why I ask is, as long as I use the standard values from nRF it would work I guess. But when I create my own network it automatically creates its own mesh local prefix (learned this last week). That is the point were I need to understand how to change or form the right address to match it.

    Ps: The OnMeshPrefix is located under "/etc/border_router.conf.

    Best regards,

    Markus

  • Sorry for the late answer. I am struggling a bit to understand where you are stuck, and what the issue is.



    <p>I am not familiar with this website. Have you tried to check openthread's own <a href="">openthread.io/.../a> or guides?</p>

    Maboo said:
    But the explanations on the RFC 3306 webside are too confusing for me.

    I am not familiar with this website. Have you tried to check out openthread's own documentation or guides?

    Maboo said:
    The problem why I ask is, as long as I use the standard values from nRF it would work I guess. But when I create my own network it automatically creates its own mesh local prefix (learned this last week).

    What works and what do you change, and what doesn't work after you change it? Is this something that I can reproduce using a couple of nRF52840 DKs?

    I guess you have stumbled upon this guide? If not, perhaps it will answer some of your questions?

    Best regards,

    Edvin

  • Hi Edvin,

    my goal is to form my own thread network and let several SED (Sleepy End Devices - rx-off-when-idle) communicate with the border router -> Homeassistant. That means the SED wakes up every 5 min and publishes a status update. Homeassistant subscribes to the SED topic and displays the new status.

    When I form my own thread network (you can do this on the local border router website). I can connect all the sensors as FTD (Full Thread Device - rx-on-when-idle) and the thread network works perfectly.

    When I flash them as an SED (rx-off-when-idle) I think I need to change "GatewayUDP6Broadcast" address in /etc/paho-mqtt-sn-gateway.conf. to fit the new MeshLocalPrefix (which was created by forming the network) [see below] Otherwise the SED won't find a gateway.

    wpan0 => [
    "NCP:State" => "associated"
    "Daemon:Enabled" => true
    "NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
    "Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
    "Config:NCP:DriverName" => "spinel"
    "NCP:HardwareAddress" => [F4CE36791D40C566]
    "NCP:Channel" => 11
    "Network:NodeType" => "leader"
    "Network:Name" => "OpenThreadDemo"
    "Network:XPANID" => 0x1111111122222222
    "Network:PANID" => 0xABCD
    "IPv6:LinkLocalAddress" => "fe80::1028:6768:6ee4:2727"
    "IPv6:MeshLocalAddress" => "fd11:1111:1122:0:3ab1:cb84:a673:bf93"
    "IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"
    "com.nestlabs.internal:Network:AllowingJoin" => false
    ]

    If I am using the statndard network parameters from nrf, the standard MeshLocalPrefix from nrf is: "fdde:ad00:beef::/64" and the standard GatewayUDP6Broadcast is "ff33:40:fdde:ad00:beef:0:0:1". As you can see, it somehow fits. And everthing works, even if I flash it as SED.

    But if I form my own network, my MeshLocalPrefix is "fd11:1111:1122::/64", so it doesn't fit to the GatewayUDP6Broadcast address anymore + the SED can't connect to the gateway. So now is the question, do I have to create a new fitting GatewayUDP6Broadcast or is there even more I have to change to get the SED connecting to the thread network?

    The answer from Carl Richard suggested I must change the address to match the network prefix.

    But how do i do it? And which address does he mean? GatewayUDP6Broadcast? Or am I wrong here?

    First, thank you for the extensive logs. The result you see in Test 2 is expected, as SEDs doesn't support multicast address "ff03::1". I reached out to a colleague about the issue with the other address. It seems like you may be using the wrong mesh-local prefix. The default (from wpan status) should be: 

    Fullscreen
    1
    "IPv6:MeshLocalPrefix" => "fdde:ad00:beef::/64"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    but you have,
    Fullscreen
    1
    "IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    You must change the address to match the network prefix.

    Ps: the openthread documentation doesn't help me here. Regarding SEDs it just refers to the RFC 3306 webside.

  • Hello,

    Sorry for the late reply. I have tried a couple of times to get a OTBR up and running but so far with no luck. 

    I believe that the MQTT-SN Gateway uses a realm-local all thread nodes multicast address. By default the "gatewayUDP6Broadcast" address is ff33:40:fdde:ad00:beef:0:0:1. This is a multicast address defined in Thread, so all Thread devices are reached with that particular mesh-local prefix (default fdde:ad00:beef). If you use another prefix address, you need to change that in the paho configuration to use your new prefix. 

    I see that it looks like you already changed this. But I can't see that it is used in the sniffer trace that you uploaded a screenshot of earlier (and I can't see that you uploaded the actual sniffer trace, but perhaps I just can't see it. Please correct me if I am wrong). 

    This is quite down the openthread specification rabbit hole. If I knew the answer I would tell you immediately, but I can try to figure it out together with you. You may want to open some communication in an openthread forum as well, as you may get help quicker there. 

    Best regards,

    Edvin

Reply
  • Hello,

    Sorry for the late reply. I have tried a couple of times to get a OTBR up and running but so far with no luck. 

    I believe that the MQTT-SN Gateway uses a realm-local all thread nodes multicast address. By default the "gatewayUDP6Broadcast" address is ff33:40:fdde:ad00:beef:0:0:1. This is a multicast address defined in Thread, so all Thread devices are reached with that particular mesh-local prefix (default fdde:ad00:beef). If you use another prefix address, you need to change that in the paho configuration to use your new prefix. 

    I see that it looks like you already changed this. But I can't see that it is used in the sniffer trace that you uploaded a screenshot of earlier (and I can't see that you uploaded the actual sniffer trace, but perhaps I just can't see it. Please correct me if I am wrong). 

    This is quite down the openthread specification rabbit hole. If I knew the answer I would tell you immediately, but I can try to figure it out together with you. You may want to open some communication in an openthread forum as well, as you may get help quicker there. 

    Best regards,

    Edvin

Children
  • Hi Edvin,

    thanks a lot for your effort! So my current status: I tested the OTBR image from there website combined with the paho-mqtt-sn gateway and installed both on a RPi 4. There I played around a bit with the mesh local prefix and other parameters. Eventually I was able to send a gateway request from a pca10056 (flashed mqtt-sn-publisher example) by pressing the button.

    The result on gateway side was:

    pi@raspberrypi:/etc/paho.mqtt-sn.embedded-c/MQTTSNGateway/bin $ sudo ./MQTT-SNGateway 
    
     ***************************************************************************
     * MQTT-SN Gateway
     * Part of Project Paho in Eclipse
     * (https://github.com/eclipse/paho.mqtt-sn.embedded-c.git)
     *
     * Author : Tomoaki YAMAGUCHI
     * Version: 1.5.1
     ***************************************************************************
     ConfigFile  : ./gateway.conf
     ClientList  : /path/to/your_clients.conf
     Broker      : mqtt.eclipseprojects.io : 1883, 8883
     RootCApath  : (null)
     RootCAfile  : (null)
     CertKey     : (null)
     PrivateKey  : (null)
     SensorN/W   : Multicast Address: [ff33:40:fdde:ad00:beef:0:0:1]:1883, Gateway Port:47193, Interface: wpan0, Hops:1
     Max Clients : 30
    
    20211202 092716.374 PahoGateway-01 starts running.
    
    
    20211202 092719.544   SEARCHGW          <---  Client                              03 01 01
    20211202 092719.545   GWINFO            --->  Clients    

    The Result on DK side via JLinkLogger was:

    SEGGER J-Link V7.50 - Real time terminal output
    J-Link OB-SAM3U128-V2-NordicSemi compiled Feb  2 2021 16:47:20 V1.0, SN=683835218
    Process: JLinkExe
    <info> app_timer: RTC: initialized.
    <info> app: Thread version   : OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr  5 2020 21:51:18
    <info> app: Network name     : NordicOpenThread
    <info> app: Thread interface has been enabled.
    <info> app: 802.15.4 Channel : 11
    <info> app: 802.15.4 PAN ID  : 0xABCD
    <info> app: Radio mode       : rx-on-when-idle
    <warning> app_timer: RTC instance already initialized.
    <info> app: State changed! Flags: 0x011FD33D Current role: 1
    
    <info> app: State changed<info> app: State changed! Flags: 0x00000064 Current role: 3
    
    <info> app: MQTT-SN event: Gateway discovery procedure has finished.
    
    <info> app: MQTT-SN event: Gateway discovery result: 0x3.

    0x3 means, it couldn't find an active gateway. 0x0 should have been the answer. I still think I mix stuff up regarding all the addresses.

    So just to make it clear to myself: If I have a different mesh local prefix and I want to change the old one. I just have to change the old one inside the paho gateway config:

    • new mesh local prefix e.g.: "fd11:1111:1122::/64"
    • results in "gatewayUDP6Broadcast" address ff33:40:fd11:1111:1122:0:0:1 ??

    The sniffer results are quite old. I haven't used the standard mesh local prefix there. But I can create new ones.

    Good idea, I will ask the question in an openthread forum as well.

    Best regards,

    maboo

Related