IDM-2.1 Test 21 Reading WiFiNetworkDiagnostics BeaconLostCount errors out when not connected to wifi

[cm-s-dev]

Problem

Read action results in 'No Memory' error on RPI Controlee.
Error retrieving data from clusterId: 0x0000_0037, err = ../../examples/all-clusters-app/linux/third_party/connectedhomeip/src/system/TLVPacketBufferBackingStore.cpp:88: CHIP Error 0x0000000B: No memory CHIP:DMG: <RE:Run> We cannot put more chunks into this report. Enable chunking. CHIP:DMG: <RE> Sending report (payload has 1234 bytes)...

Controller fails with IM Error 0x00000501: General error: 0x01 at ../../commands/common/CHIPCommand.cpp:62

Commands

chip-tool any read-by-id 0xFFFFFFFF 0xFFFFFFFF 1 0

Test Setup:

chip-tool and chip-all-clusters-app:
commit 5cbe2931f64e16a44fc843e148325909fbe1511d (tag: TE8/rc3)

Log

IDM-2.1_test21_error.txt

[bzbarsky-apple]

The "no memory" bit above is expected.

Controller fails with IM Error 0x00000501: General error: 0x01 at ../../commands/common/CHIPCommand.cpp:62

@cm-s-dev Are those the complete logs? The server is only sending things for cluster 0x0004 but the client is only receiving things for cluster 0x0035?

[cm-s-dev]

This is a snippet from the log which is very large.
The 'No Memory' message and chunking for reports occurs multiple times before eventually the controller fails with those errors in the log file.
Seems like the process was working fine until that error code occurs. Not sure what it means.

[cm-s-dev]

Attached the more log for all-clusters-app.
It shows another error message,
[1646848063.933619][1150:1150] CHIP:ZCL: The WiFi interface is not currently configured or operational. [1646848063.933694][1150:1150] CHIP:DMG: <RE:Run> Cluster 36, Attribute 5 is dirty [1646848063.933799][1150:1150] CHIP:DMG: Reading attribute: Cluster=0x0000_0036 Endpoint=0 AttributeId=0x0000_0005 (expanded=1) [1646848063.933859][1150:1150] CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0036 e=0 p=v [1646848063.934044][1150:1150] CHIP:DMG: Error retrieving data from clusterId: 0x0000_0036, err = ../../examples/all-clusters-app/linux/third_party/connectedhomeip/src/platform/Linux/ConnectivityUtils.cpp:464: CHIP Error 0x000000AE: Read from file failed [1646848063.934133][1150:1150] CHIP:DMG: <RE:Run> Cluster 36, Attribute 6 is dirty

all-clusters-app_ending_log.txt

[bzbarsky-apple]

[1646848063.933799][1150:1150] CHIP:DMG: Reading attribute: Cluster=0x0000_0036 Endpoint=0 AttributeId=0x0000_0005 (expanded=1) 
[1646848063.933859][1150:1150] CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0036 e=0 p=v 
[1646848063.934044][1150:1150] CHIP:DMG: Error retrieving data from clusterId: 0x0000_0036, err = ../../examples/all-clusters-app/linux/third_party/connectedhomeip/src/platform/Linux/ConnectivityUtils.cpp:464: CHIP Error 0x000000AE: Read from file failed

Yes, that makes sense: failed read, which is then sent as an error to the client, etc. And the cluster/attribute ids are consistent with when the client reports an error.

We are reading cluster 0x0036, attribute 0x5, which is the "WiFiNetworkDiagnostics" cluster attribute "BeaconLostCount".

Is the server on wifi? Because the Linux impl of GetWiFiBeaconLostCount does:

    if (ConnectivityMgrImpl().GetWiFiIfName() == nullptr)
    {
        return CHIP_ERROR_READ_FAILED;
    }

which is where I think you are ending up.

[cm-s-dev]

Actually yes, server is on wired, and client is on wifi.
Thats probably the cause.

[bzbarsky-apple]

Spec here does not allow returning null, but maybe it should?

Alternately, maybe we should just return 0 if we are not on wifi at all?

@tcarmelveilleux @yufengwangca

[woody-apple]

Spec Review: @anush-apple can you please review this to see if this is a spec compliance issue, and/or if we should update the spec.

[robszewczyk]

@yufengwangca is this still erroring out or did you fix it in one of the more recent iterations of the work in the diagnostics clusters?

[yufengwangca]

This issue should be fixed in #21653 on the SDK side.

[franck-apple]

Closing per @yufengwangca's above comment.