[BUG][TC-DGWIFI-2.1] BeconRxCount attribute value mismatches from specification

[Survensa]

Feature Area

Other

Test Case

TC-DGWIFI-2.1

Reproduction steps

1. Bring up the DUT with all-cluster-app.
2. Pair the DUT using chip-tool through "ble-wifi" transport.
3. Run the command ./chip-tool wifinetworkdiagnostics read beacon-rx-count 1 0

Bug prevalence

Whenever I try to read beacon-rx-count.

GitHub hash of the SDK that was being used

2767b51 - Master

Platform

raspi

Platform Version(s)

RPI4 8GB RAM

Anything else?

As per spec the BeaconRxCount attribute SHALL indicate the count of the number of received beacons. The total number of expected beacons that could have been received during the interval since association SHOULD match the sum of BeaconRxCount and BeaconLostCount. If the Node does not have an ability to report count of beacons received, this value MAY remain set to zero.

In master commit while trying to read the BeaconRxCount TH reads NULL from DUT.

Attached log for reference: TC-DGWIFI-2-2.txt

[bzbarsky-apple]

The Linux version of DiagnosticDataProvider does not implement GetWiFiBeaconRxCount so the count is not available and null is returned.

Sounds like it should be implemented and return 0 when we are associated. Similar for BeaconLostCount.

I wonder whether we can just automatically do this in the wifi network diagnostics cluster if we get CHIP_ERROR_UNSUPPORTED_CHIP_FEATURE....

[cecille]

Null is a valid value here though. There is an X in the quality column. So if you're getting back null, that's valid, and if the test plans says otherwise, we should fix the test plan.

[bzbarsky-apple]

Null is a valid value here though

Not when the device is actually attached to a wifi network @cecille.

[cecille]

Does it actually say that? The spec says the value MAY remain zero, but there's nothing that says it has to be non-null if you're connected.

[bzbarsky-apple]

The spec says:

For all attributes listed above, a null value SHALL be returned if the interface is not currently configured or operational.

It should probably be clearer about this, but the intent as I recall it was that if not configured you get null, else you get non-null values. We just had a really hard time getting people to clearly write things out for each attribute....

[cecille]

Oh, interesting. OK, I think I it kind of makes sense then to assume that the opposite also applies, though it might be good to clarify. I suppose the de-facto rule is whatever we implement in the SDK, so if you want 0 returned, we should do that since that's definitely allowed in the spec.

[bzbarsky-apple]

I think 0 would make a lot of sense here, yes.

[Survensa]

Issue resolved