OTBR forwards messages between the Thread network and the wifi network failed

[chuckrui]

I tested it with the following steps, but it seems that OTBR cannot forward switch control bulb instructions in thread and wifi networks.

Hardware and software configuration：

1. Raspberry Pi 4B is used as a Board Router.
2. nRF52840 dongle, burn coprocesse firmware as RCP inserted in the USB port of Pi 4B.
3. A WIFI router that supports IPV6.
4. Raspberry PI burns ubuntu.

Test procedure：

1.Install the Border Router using docker.

(1) Start the Docker daemon sudo systemctl start docker

(2)Create an IPV6 network in Docker for the OpenThread Border Router container. sudo docker network create --ipv6 --subnet fd11:db8:1::/64 -o com.docker.network.bridge.name=otbr0 otbr

(3)Download a compatible version of the OpenThread border Router docker image sudo docker pull nrfconnect/otbr:a892bf7

(4)Ensure that packets sent to devices in the Thread network are routed through the OpenThread Border Router container in Docker sudo ip -6 route add fd11:22::/64 dev otbr0 via fd11:db8:1::2

(5)sudo modprobe ip6table_filter

(6)Start the OpenThread border router container.

sudo docker run -it --rm --privileged --name otbr --network otbr -p 8080:80 \
--sysctl "net.ipv6.conf.all.disable_ipv6=0 net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1" \
--volume /dev/ttyACM0:/dev/radio nrfconnect/otbr:a892bf7 --radio-url spinel+hdlc+uart:///dev/radio?uart-baudrate=1000000

(7)form thread network

2.device commissioning

(1)ZGMISMART bulb ./chip-tool-debug pairing ble-wifi 1234 <ssid> <passwd> 2625296 1266 --bypass-attestation-verifier true bulb.txt

(2)switch (0x0104-Matter Dimmer Switch) ./chip-tool-debug pairing ble-thread 1235 hex:0e080000000000010000000300000f35060004001fffe0020811111111222222220708fd830c6cd5bdabcb051000112233445566778899aabbccddeeff030e4f70656e54687265616444656d6f010212340410445f2b5ca6f2a93a55ce570a70efeecb0c0402a0f7f8 20202021 3840 switch.txt

(3)write acl ./chip-tool-debug accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": [1235], "targets": [{"cluster": 6, "endpoint": 1, "deviceType": null}, {"cluster": 8, "endpoint": 1, "deviceType": null}]}]' 1234 0 acl.txt

(4)bind switch with bulb ./chip-tool-debug binding write binding '[{"fabricIndex": 1, "node": 1234, "endpoint": 1, "cluster": 6}, {"fabricIndex": 1, "node": 1234, "endpoint": 1, "cluster": 8}]' 1235 1 binding.txt

Three points worth mentioning:

1. Can normally control the lamp on/off, brightness, color temperature
2. The acl and bind operations can also be queried correctly
3. the following commands run properly

//onoff control ./chip-tool-debug onoff on 1234 1 onoff.txt

//colorcontrol ./chip-tool-debug colorcontrol move-to-hue-and-saturation 240 100 0 0 0 1234 1

//levelcontrol ./chip-tool-debug levelcontrol move-to-level Level=10 TransitionTime=0 OptionMask=0 OptionOverride=0 1234 1 levelcontrol.txt

//read acl ./chip-tool-debug accesscontrol read acl 1234 0 read_acl.txt

//read binding ./chip-tool binding read binding 1235 1 read_binding.txt

Test problem：

The switch does not control the on/off and levelcontrol of the ZGMISMART bulb. Is it because OTBR did not forward the switch in the thread network to the light bulb in the wifi network?

More information：

1.switch log switch_log.txt

2.switch endpoint info

[bzbarsky-apple]

The relevant bit from the switch log:

[10:40:58.253] I: 1171280 [DIS]Resolving 8C5092A3A22EDA8A:00000000000004D2 ...
...
[10:41:43.255] E: 1216285 [DIS]OperationalSessionSetup[1:00000000000004D2]: operational discovery failed: 32

So it never manages to do the DNS-SD resolve. "32" is CHIP_ERROR_TIMEOUT, not surprisingly.

It seems like the SRP server in question is not doing an mDNS resolve to find the light bulb, or perhaps the switch is not asking the SRP server at all. You should probably look at logs from the SRP server to see what it's getting here.

[bzbarsky-apple]

@chuckrui See above.

[chuckrui]

@bzbarsky-apple

ifconfig.txt The switch is carried out by the way of ble thread, but the light bulb is distributed by the way of ble wifi, so the OTBR needs to transfer the switch control command from the Thread network to the lamp in the wifi network. Is there anything wrong with that?

But I look at the network device displayed in the "ifconfig" of my raspberry PI, OTBR0 is not in network segment 3, that is to say, it does not exist in the same wifi network as the light bulb.

About the SRP service related log you said, where do I need to find? I found the source of the error in the code.

And from what I understand, isn't the border router just an SRP server? Below are some logs of OTBR operation, where I have operated the BTN on the switch to try to control the light bulb, but the result is no reaction. otbr-log.txt

[chuckrui]

@bzbarsky-apple I used the same method, steps and commands as above, the only difference is that the light bulb was changed to a ble thread, and the switch could normally control the light bulb, so I doubt whether it is still the problem of OTBR.

[bzbarsky-apple]

And from what I understand, isn't the border router just an SRP server?

Generally, but not always.

This really needs someone familiar with Thread details to look at it...