chip tool starts resolve to soon

[doublemis1]

Problem

Chip tool using ble-thread command proceed the whole commissioning and after that resolve the IP address of a commissioned node.
Chip tool sends resolve command immediately after callback from enabling Thread network, which may cause that accessory can be still in attaching procedure while controller wants to resolve IP address. If the previous commissioning session used the same fabric id and node id the controller can get the wrong IP address.

Proposed Solution

For the current implementation of the resolve and chip tool. The chip tool should wait 2-3 seconds between enabling the thread network and resolving the IP address.
It will be helpful if, in the chip tool, the user can define the node id.

[bzbarsky-apple]

The chip tool should wait 2-3 seconds between enabling the thread network and resolving the IP address.

Shouldn't the accessory side not respond until it's executed the command and joined the network? How is this expected to work per spec?

It will be helpful if, in the chip tool, the user can define the node id.

This part we should definitely do. Filed #8436

[Damian-Nordic]

@bzbarsky-apple The thing is that Thread devices don't respond on their own. They register their service upon startup in the OpenThread Border Router using the SRP protocol. OTBR then monitors the registered services and updates a mDNS daemon accordingly (be it mDNS Responder or Avahi), which in turn acts as the mDNS server. The architecture creates some delay and if node IDs are reused, some components like mDNS client or server may still return cached entries. I think our tests should either make sure that old DNS entries are cleaned up (for example, by handling RemoveFabric command properly) before factory-resetting a device, or use random node IDs.

[bzbarsky-apple]

@Damian-Nordic Thank you for the context!

I changed chip-tool to use random node ids by default in #8450. That does not affect CI (purposefully), but in CI this should not be a problem, I hope....

If that's not enough for our purposes, we should see what else we should do to ensure unique node ids or the DNS entry cleanup you suggest. In particular, we might need to do something with chip-device-ctrl, which will just use whatever node id you tell it to and hence can lead to reuse...

I do think the right thing here is to ensure node id uniqueness, not add sleep() workarounds for lack thereof.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[bzbarsky-apple]

This has been fixed by adding retries to operational discovery, which gives the new node time to come up.