Running OpenThread Border Router in Docker?

What are the limitations for running OpenThread Border Router in Docker?

I have not been able to successfully use it to build a Thread network and join Matter devices to it. I would like to be able to setup and run it in a Docker container and use it as if I installed the OTBR software on bare metal.

If I run on bare metal, I can use this command running on another computer to see the service:

avahi-browse -r -t _meshcop._udp

If I run OTBR in Docker and run the above command, I cannot see any services.

It looks like to network traffic from the Docker container isn't properly integrated with the LAN network.

Have anyone successfully done this?



Parents
  • Hi,

    Did you follow the guide here Thread Border Router? There are steps for running OTBR using Docker there.

    Best regards,
    Marte

  • Yes, I have tried following the steps in that article.

    It's a bit unclear to me what this means:

    "For development purposes, you can run the OpenThread Border Router on any Linux-based system using a Docker container that already has the Border Router installed. This solution can be used when you are only interested in direct communication between your Border Router and the Thread network. For example, you can use the Docker container when you want to establish IP communication between an application running on Linux (such as the CHIP Tool Matter controller) and an application running on a Thread node."

    What exactly are the restrictions are there when running OTBR in a Docker container compared with running it on bare metal? 

  • I see from your logs that you are not running any of our Matter samples. Are you getting the same issue with our Matter samples as well? You can find a list of samples here: Matter samples.

    Which board are you using?

  • You don't seem to understand the issue. The issue is not related to the board running the Matter End Device, but it's related to the OpenThread Border Router running in a Docker container and the RCP. The RCP board is the nRF52840 USB Dongle.

    Why don't you try to re-produce in your environement?

  • I tried to reproduce the issue last week using the nRF52840 DK and our light bulb sample, but I did not get any issues.

    The commissioning fails during operational discovery, which is the step where the chip-tool uses DNS-SD to discover the device and its IP address. This issue could occur due to network issues or incorrect configuration of the Thread network, but I cannot say for certain that it is not due to the device when you are testing with a third party device and/or code.

    For the RCP, did you use the co-processor sample in the nRF Connect SDK and build it with overlays for USB? I have attached the hex file I used for the RCP when testing. You can use the nRF Connect Programmer app to program the dongle.

    Are you running chip-tool on the same computer as the docker OTBR, or on a separate computer?

    Please share the output you get when checking the status of the OTBR and Thread node, i.e. steps 10 and 11 in the guide for running OTBR using docker:

    10. Check the status of the OpenThread Border Router by executing the following command:

    sudo docker exec -it otbr sh -c "sudo service otbr-agent status"
    

    11. Check the status of the Thread node running inside the Docker:

    sudo docker exec -it otbr sh -c "sudo ot-ctl state"
    

    4617.zephyr.hex

  • "I tried to reproduce the issue last week using the nRF52840 DK and our light bulb sample, but I did not get any issues."

    Can you describe your lab setup?

    "Are you running chip-tool on the same computer as the docker OTBR, or on a separate computer?"

    On a separate computer.

  • Izvor said:

    "Are you running chip-tool on the same computer as the docker OTBR, or on a separate computer?"

    On a separate computer.

    Please try running chip-tool on the same computer.

    Izvor said:

    "I tried to reproduce the issue last week using the nRF52840 DK and our light bulb sample, but I did not get any issues."

    Can you describe your lab setup?

    Setup:

    • A computer with Ubuntu 20.04 for docker OTBR and chip-tool.
    • nRF52840 Dongle for RCP, running the co-processor sample as described in Configuring a radio co-processor.
    • nRF52840 DK with the light bulb sample.
    • SDK: nRF Connect SDK v2.5.1

    The chip-tool was built manually from sources as described in Building the CHIP Tool, and I followed the Running OTBR using Docker for the OTBR. In step 7 I used the GUI to form the Thread network. I ran the chip-tool on the same computer as the docker OTBR.

Reply
  • Izvor said:

    "Are you running chip-tool on the same computer as the docker OTBR, or on a separate computer?"

    On a separate computer.

    Please try running chip-tool on the same computer.

    Izvor said:

    "I tried to reproduce the issue last week using the nRF52840 DK and our light bulb sample, but I did not get any issues."

    Can you describe your lab setup?

    Setup:

    • A computer with Ubuntu 20.04 for docker OTBR and chip-tool.
    • nRF52840 Dongle for RCP, running the co-processor sample as described in Configuring a radio co-processor.
    • nRF52840 DK with the light bulb sample.
    • SDK: nRF Connect SDK v2.5.1

    The chip-tool was built manually from sources as described in Building the CHIP Tool, and I followed the Running OTBR using Docker for the OTBR. In step 7 I used the GUI to form the Thread network. I ran the chip-tool on the same computer as the docker OTBR.

Children
  • Ok, not strange that it works when you are running everything on one computer!

    In my original question:

    "If I run on bare metal, I can use this command running on another computer to see the service

    avahi-browse -r -t _meshcop._udp

    If I run OTBR in Docker and run the above command, I cannot see any services." (when run from another computer)

    Isn't it supposed to work across multiple computers? Like it does when running on bare metal?

  • Hi,

    You need to run the chip-tool on the same computer as the one running the OTBR in docker. I apologize if my previous replies caused confusion regarding this.

    Best regards,
    Marte

  • Ok, so it's not possible to run OTBR in a Docker container and make it participate in a LAN network as you can with a OTBR running on bare metal?

  • Hi,

    I have asked the developers to verify this. I will let you know when I hear back from them.

    Best regards,
    Marte

  • Hi,

    The docker OTBR does not work like this out-of-the-box, as it is meant to be used for local/simple setup and we recommend using OTBR. However, it is possible to configure the docker OTBR to run on a host network, which will make it work similarly to if you run the OTBR on bare metal.

    To do so, you must do the following:

    1. Define which interface is used as connection to the WAN/LAN (e.g. eth0, wlan0)
    2. Set RA/ROI for that interface
      sudo sysctl net.ipv6.conf.$BACKBONE_INF.accept_ra_rt_info_max_plen=128
      sudo sysctl net.ipv6.conf.$BACKBONE_INF.accept_ra=2
    3. Run docker container using following command (provide the configured interface as $BACKBONE_INF)
      docker run --rm --privileged --network host --name otbr --volume /dev/ttyACM0:/dev/ttyACM0 nrfconnect/otbr:9185bda --radio-url spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200 -B $BACKBONE_INF
    4. Form topology

    Please note that the OTBR might not clean all the configurations after removing the docker, so some leftovers might still be on the host. This is why we only recommend using OTBR in docker for local and simple setup.

    Best regards,
    Marte

Related