Swapping RCP => OTBR not working?

[olavt]

I'm testing swapping RCPs on a OTBR.

First I setup everything using one RCP by forming a network and add a Matter over Thread device. I check that chip-tool can get some responses from the device (like read a temperature).

Response from "sudo ot-ctl state" is:

router
Done

Then I swap the RCP and re-start.

Now chip-tool times out when trying to get a response from the device.

Response from "sudo ot-ctl state" is:

disabled
Done

$ sudo service otbr-agent status
● otbr-agent.service - OpenThread Border Router Agent
Loaded: loaded (/lib/systemd/system/otbr-agent.service; enabled; preset: enabled)
Active: active (running) since Thu 2024-01-18 23:00:53 GMT; 6min ago
Process: 557 ExecStartPre=/usr/sbin/service mdns start (code=exited, status=0/SUCCESS)
Main PID: 810 (otbr-agent)
Tasks: 1 (limit: 8740)
CPU: 226ms
CGroup: /system.slice/otbr-agent.service
└─810 /usr/sbin/otbr-agent -I wpan0 -B eth0 spinel+hdlc+uart:///dev/ttyACM0 trel://eth0

Jan 18 23:00:54 otbr otbr-agent[810]: [INFO]-BA------: Publish meshcop service OpenThread BorderRouter #9A07.meshcop.>
Jan 18 23:00:54 otbr otbr-agent[810]: 00:00:00.091 [I] RouterTable---: Route table
Jan 18 23:00:54 otbr otbr-agent[810]: 00:00:00.098 [I] Platform------: [netif] Host netif is down
Jan 18 23:00:54 otbr otbr-agent[810]: 00:00:00.099 [I] Platform------: [netif] Succeeded to process request#1
Jan 18 23:00:54 otbr otbr-agent[810]: [INFO]-MDNS----: Successfully registered service OpenThread BorderRouter #9A07._m>
Jan 18 23:00:54 otbr otbr-agent[810]: [INFO]-BA------: Result of publish meshcop service OpenThread BorderRouter #9A07.>
Jan 18 23:00:54 otbr otbr-agent[810]: [INFO]-BA------: Result of publish meshcop service OpenThread BorderRouter #9A07.>
Jan 18 23:02:18 otbr otbr-agent[810]: 00:00:50.391 [I] Platform------: Session socket is ready
Jan 18 23:02:39 otbr otbr-agent[810]: 00:01:10.762 [I] Platform------: Session socket is ready
Jan 18 23:02:39 otbr otbr-agent[810]: 00:01:10.763 [W] Platform------: Daemon read: Connection reset by peer

Then I swap back to the first RCP and everything is back to normal.

What could be the issue here? Isn't a RCP swap supposed to be no issue?

[jwhui]

The OT settings filename is based on the IEEE EUI-64 reported by the RCP:

openthread/src/posix/platform/settings.cpp

Lines 90 to 93 in ae6eff5

	otPlatRadioGetIeeeEui64(aInstance, reinterpret_cast<uint8_t *>(&nodeId));
	nodeId = ot::BigEndian::HostSwap64(nodeId);
	snprintf(aFileName, kMaxFileNameSize, OPENTHREAD_CONFIG_POSIX_SETTINGS_PATH "/%s_%" PRIx64 ".%s",
	offset == nullptr ? "0" : offset, nodeId, (aSwap ? "swap" : "data"));

If you want to be able to seamlessly swap RCPs that have different IEEE EUI-64 values, you can try changing the implementation to use a fixed filename.

[olavt]

Ok, so afer swapping a RPC , I could also copy the settings file from the old RPC to the file for the new RPC?

[jwhui]

If you copy the file, you'll need to do that before starting the OT process, but that requires knowing the new IEEE EUI-64 value beforehand.

As mentioned in https://github.com/orgs/openthread/discussions/9786#discussioncomment-8175044, I would try using a fixed filename instead.

[olavt]

Couldn’t you stop the OT. Copy the file and than start the OT again?

[jwhui]

You could, but that sounds like more work for something less robust than simply having a hard-coded filename.

[olavt]

Is the IEEE EUI-64 value unique for every single RCP, or only for different vendor / product?

[abtink]

It is supposed to be unique per RCP. EUI stands for "Extended Unique Identifier"
https://en.wikipedia.org/wiki/Organizationally_unique_identifier#64-bit_extended_unique_identifier_(EUI-64)

[olavt]

Thanks! I have now tested and confirmed that I'm able to preserve the OpenThread settings after swapping the RPC by copying the correct settings file in the /var/lib/thread directory.