Can't reach thread devices from docker container in bridge network

[jhoogstraat]

Running openthread/otbr:latestin a docker bridge network I can ping thread devices from within just fine:

# ot-ctl
childip
8401: fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279
8401: fdd4:761:7313:1:b7b4:58db:b67b:86bb
Done
> ping fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279
16 bytes from fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279: icmp_seq=1 hlim=64 time=2999ms
1 packets transmitted, 1 packets received. Packet loss = 0.0%. Round-trip min/avg/max = 2999/2999.0/2999 ms.
Done
> 

When I now start a second container in the same bridge network I can of cause ping the otbr-container just fine, but thread devices are not in reach:

ping fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279
PING fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279 (fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279) 56 data bytes
From fd11:db8:1::1 icmp_seq=10 Destination unreachable: No route

So I added a ipv6 route using the infos from

root@otbr:/app# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd11:db8:1::1f/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::3cbc:eeff:fe9f:b8af/64 scope link 
       valid_lft forever preferred_lft forever
3: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 state UNKNOWN qlen 500
    inet6 fd68:3d86:8478:b1cd:0:ff:fe00:fc11/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fdd4:761:7313:1:40ff:dbf5:34b0:c469/64 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fd68:3d86:8478:b1cd:0:ff:fe00:fc10/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd68:3d86:8478:b1cd:0:ff:fe00:fc38/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd68:3d86:8478:b1cd:0:ff:fe00:fc00/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd68:3d86:8478:b1cd:0:ff:fe00:8400/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fd68:3d86:8478:b1cd:bf75:c27a:749e:de24/64 scope global nodad deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::6420:5f5c:11eb:1552/64 scope link nodad 
       valid_lft forever preferred_lft forever

to the second container like so:
ip -6 route add fd68:3d86:8478:b1cd::/64 via fd11:db8:1::1f.

Now I can reach the fd68-prefixed addresses:

# ping6 fd68:3d86:8478:b1cd:0:ff:fe00:fc11
PING fd68:3d86:8478:b1cd:0:ff:fe00:fc11 (fd68:3d86:8478:b1cd:0:ff:fe00:fc11): 56 data bytes
64 bytes from fd68:3d86:8478:b1cd:0:ff:fe00:fc11: seq=0 ttl=64 time=0.193 ms
64 bytes from fd68:3d86:8478:b1cd:0:ff:fe00:fc11: seq=1 ttl=64 time=0.211 ms

but thread devices themselfes still not. I get a Message dropped by Thread log from the agent:

# ping6 fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279
PING fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279 (fd68:3d86:8478:b1cd:71a9:8be2:9f75:3279): 56 data bytes

and the agent:

Jan 30 15:43:50 otbr otbr-agent[122]: 00:38:21.725 [I] P-Netif-------: Message dropped by Thread
Jan 30 15:43:51 otbr otbr-agent[122]: 00:38:22.725 [I] P-Netif-------: Message dropped by Thread
Jan 30 15:43:52 otbr otbr-agent[122]: 00:38:23.726 [I] P-Netif-------: Message dropped by Thread
Jan 30 15:43:53 otbr otbr-agent[122]: 00:38:24.726 [I] P-Netif-------: Message dropped by Thread
Jan 30 15:43:54 otbr otbr-agent[122]: 00:38:25.726 [I] P-Netif-------: Message dropped by Thread

My requierements are that all containers run via podman on the same host (a pi) and have the least amount of privileged required. The only way I was able to make it work is put both container in one pod. But than I have to give every container full root permissions.

• What is the intended way for external devices to reach thread devices (or why is my request being blocked here)?
• Is there a better way, given the constraints, to lay out the network?

[jwhui]

A Thread Border Router relies on sending IPv6 Router Advertisements on the infrastructure link to properly configure IPv6 addresses and routes. In your case, the infrastructure link should be the bridge network.

fd11:db8 appears to be a manually configured IPv6 prefix. If that prefix is not being advertised in IPv6 Router Advertisements, the Thread Border Router will not learn that as an on-link prefix on the infrastructure network.

[jhoogstraat]

Hi, thank you for the quick reply!

Thats interesting. I did not know that the prefix of the subnet of the infrastructure network (here the bridge network eth0 inside the containers) should be used in the mesh.

The subnet fd11:db8:1:: was auto-created by podman network create, so that will always stay a manually configured IPv6 prefix (from the border router perspective). The mesh was formed using the thread home assistant integration, so that is something that might not work in this case.

I will also check for RA packets on the bridge network. I am not sure if it is possible to influence that in podman/docker, though.

Having no experience in the otbr repo, is it unclear to me, why the veth in the second container (home assistant) is not also advertised and able to connect the thread devices. I am pretty sure the problem lies in the bridge, because when running both container on a single pod (aka they share the same interface and talk via localhost) it does work fine (via podman kube play and setting the thread network up via home assistant).