provisioning raspi accessory not successful with chip-tool on mac

[cjandhyala]

With ToT (7283e3a) provisioning raspi accessory not successful with chip-tool on mac, chip-tool fails to establish CASE session after resolving the nodeID. However the IP address resolved in the resolve API is reachable.

Steps to reproduce

1. build all-clusters-app on raspi with ToT (7283e3a) using 'scripts/examples/gn_build_example.sh examples/all-clusters-app/linux/ out/all-clusters-app'
2. launch the app using 'sudo ./out/all-clusters-app/chip-all-clusters-app --wifi'
3. build chip-tool controller using 'gn gen out/debug --args='chip_mdns="platform"' and 'ninja -C out/debug
   '
4. provision the app with chip-tool using 'sudo ./out/debug/chip-tool pairing ble-wifi 1234 20202021 3840
   '
5. Observed controller is not able to establish CASE session. However mac is able to ping the IP address resolved in the resolve API.

% ping6 fde2:1151:8029:0:dea6:32ff:fe8d:7073
PING6(56=40+8+8 bytes) fde2:1151:8029:0:a006:53db:9180:9da8 --> fde2:1151:8029:0:dea6:32ff:fe8d:7073
16 bytes from fde2:1151:8029:0:dea6:32ff:fe8d:7073, icmp_seq=0 hlim=64 time=130.187 ms
16 bytes from fde2:1151:8029:0:dea6:32ff:fe8d:7073, icmp_seq=1 hlim=64 time=4.039 ms
16 bytes from fde2:1151:8029:0:dea6:32ff:fe8d:7073, icmp_seq=2 hlim=64 time=4.928 ms
^C

Attached logs

raspi-log.txt
chip-tool-log.txt

[msandstedt]

I am able to get this working in the code introduced here: #13294.

However, this requires a workaround to #13274.

The workaround is:

diff --git a/src/commissioner/Discoverer.h b/src/commissioner/Discoverer.h
index d3ea42f29..f5a9a9ee2 100644
--- a/src/commissioner/Discoverer.h
+++ b/src/commissioner/Discoverer.h
@@ -90,6 +90,26 @@ public:
     CHIP_ERROR GetNextDnssdCandidate(Commissionee & commissionee);
 
 private:
+
+void OnNodeDiscoveryComplete(const chip::Dnssd::DiscoveredNodeData & nodeData)
+{
+    auto discoveredNodes = GetDiscoveredNodes();
+    // Node not yet in the list
+    for (auto & discoveredNode : discoveredNodes)
+    {   
+        if (!discoveredNode.IsValid())
+        {   
+            discoveredNode = nodeData;
+            if (mDeviceDiscoveryDelegate != nullptr)
+            {   
+                mDeviceDiscoveryDelegate->OnDiscoveredDevice(nodeData);
+            }   
+            return;
+        }   
+    }   
+    ChipLogError(Discovery, "Failed to add discovered node with hostname %s- Insufficient space", nodeData.hostName);
+}
+
     DiscoveredNodeList GetDiscoveredNodes() { return DiscoveredNodeList(mNodes); }
     void OnDiscoveredDevice(const chip::Dnssd::DiscoveredNodeData & node) { (*mDelegate)->OnDiscovery(); }
     void OnNodeIdResolved(const Dnssd::ResolvedNodeData & nodeData) {}

[woody-apple]

@cjandhyala Is this still broken? I'm confused how tests are passing if so...

[msandstedt]

What I had encountered was that I had some sort of vlan or virtual adapter that caused me to receive advertisements with link-local or ULA addresses that weren't reachable alongside other advertised address from the same node that were reachable.

The existing commissioning code picks the first address it sees. If this address is not reachable, commissioning fails. My solution to this was complex. #13294 is a draft PR with an alternative commissioner implementation that, among other things, uses browse to collect many candidate addresses and will try PASE with as many as it can within timeout constraints. This + a workaround for #13274 allowed me to still commission in a case where I was seeing multiple addresses, and only some were actually reachable.

I do not know for sure whether the issue encountered here is the same. But I do know that if our commissioning code sees multiple advertised addresses and not all are routable for the recipient, commissioning will likely fail.