can not pass the [TC-DD-2.1] in Android platform

[nicelyjust]

Problem

when tested [TC-DD-2.1] Announcement by Device Verification [DUT - Commissionee] through tv-app or tv-casting-app , failed in step #14b &14c , when execute the below command in chip-tool ,

avahi-browse _services._dns-sd._udp -r

can not get the Expected Outcome

Example output using all-clusters-app's advertisements:
11:30:36.040  Add        3   7 .                    _sub.local.          _L3840
11:30:36.040  Add        3   7 .                    _sub.local.          _S15
11:30:36.040  Add        2   7 .                    _sub.local.          _CM

Proposed Solution

I'm not sure whether is a problem of the DNS-sd implement in Android platform, Appreciated for any response.

[andy31415]

@nicelyjust Please update the bug with full description of steps and requirements. Specifically what are #14b &14c ? What commands are to be executed before that.

Please provide a list of commands for me to execute to reproduce the issue.
Also: what sha of the apps is being used?

[andy31415]

Assuming test case is: https://github.com/project-chip/connectedhomeip/blob/master/src/app/tests/suites/certification/Test_TC_DD_2_1.yaml

[andy31415]

The test seems to use RFC 6763 9. Service Type Enumeration (https://www.rfc-editor.org/rfc/rfc6763.html#page-27) to try to figure out if the device advertises the specified subtypes.

[andy31415]

How can I run the tv-ap or tv-casting app to verify what is going on?

[nicelyjust]

Hi Andy @andy31415 :

SDK SHA: f046787
precondition： ensure the tv-app or tv-casting app is commissioning state and is transport-connected ( Wi-Fi or Ethernet)
then execute the below command to discover in your linux | macOS

avahi-browse _services._dns-sd._udp -r 
#or
dns-sd -B _services._dns-sd._udp -r

[nicelyjust]

The test seems to use RFC 6763 9. Service Type Enumeration (https://www.rfc-editor.org/rfc/rfc6763.html#page-27) to try to figure out if the device advertises the specified subtypes.

yes, I think so

[andy31415]

@nicelyjust ensure the tv-app or tv-casting app is commissioning state and is transport-connected

I have never run tv-app or tv-casting-app ... could you help with instructions on running?

[andy31415]

I was told https://github.com/project-chip/connectedhomeip/blob/master/examples/tv-casting-app/android/README.md exists ... so that seems a good start, will try it.

[andy31415]

Looking to debug this with ./out/linux-x64-minmdns/minimal-mdns-client.

I observe results being returned on a query, but only on the first request. After that, it seems the query is not answered anymore.

[andy31415]

Dnssd logic seems to have been added in #9884 by @xylophone21 .

It uses NsdManger to register services. I am not sure if the behavior we are seeing is a regression or it never fully advertised. I believe it does advertise at boot, however I do not see NsdManager responding to queries that are done once the application runs.

[andy31415]

It seems that service publishing does not keep a MulticastLock (but resolution does), so publishing is not persistent.

After fixing that, publish works however browsing for services will NOT return _sub. However running things like ./out/linux-x64-minmdns/minimal-mdns-client -q _T35._sub._matterc._udp.local does yield results, so the data seems to be there.

[andy31415]

I see:

> # This is a valid subtype
> avahi-browse _T35._sub._matterc._udp
+ wlp57s0 IPv6 2D1858D8557DB2FE                              _matterc._udp        local
+ wlp57s0 IPv4 2D1858D8557DB2FE                              _matterc._udp        local
+ enp58s0 IPv6 2D1858D8557DB2FE                              _matterc._udp        local
+ enp58s0 IPv4 2D1858D8557DB2FE                              _matterc._udp        local

> # This is NOT a valid subtype (no responses returned)
> avahi-browse _T36._sub._matterc._udp
^CGot SIGINT, quitting.

[andy31415]

Regarding the test, https://www.rfc-editor.org/rfc/rfc6763.html#section-9 does not seem to say that subtypes are to be enumerated (but does not prevent it either).

I believe the test case needs updating or accepting alternate ways of verifying (like resolving the direct subtype like I did above).

[lisaaaas]

I also encountered the same problem, running the instruction "avahi-browse _services._dns-sd. _udp-r" failed, what is the specific solution?

[chrisdecenzo]

the fix improves the Android mDNS behavior but it does not address the issue with TC-DD-2.1 and TC-SC-4.1 since Android still does not respond to subtype queries.

The spec does not state that subtype queries are mandatory so probably the solution is to update TC-DD-2.1 and TC-SC-4.1 since these are currently mandatory.

[tcarmelveilleux]

The fact that NsdManager cannot properly respond to the subtype query in some situations does not mean we need to remove/update the spec. It is possible on Android to be directly responding to particular queries, without going through NsdManager. Furthermore, NsdManager was improved in API level 33 and 34, and I would recommend that we separate platform support from spec requirements.

[cecille]

Adding my comment here from the linked issue for context:

In my reading, these are mandatory. If they were not mandatory, then a client would never be able to rely on them and any commissionable node that did not respond on these subtypes would be sunk.

4.3.1. Commissionable Node Discovery
A commissionable Node that is already connected to an IP-bearing network SHALL only make itself discoverable on the IP network and SHALL use the relevant DNS-SD service (_matterc._udp) described below.

The subtypes are described below.

Removing this requirement would break an awful lot of things in the real world.

The service enumeration indicates that the device is meant to respond with its PTR records. Subtype PTRs are PTRs.

IMO, the argument that the DUT does not need to respond to queries for the subtypes per the spec is incorrect. These were always meant to be mandatory. In fact the _T subtype is the exception that proves the rule here - it is the only subtype marked as optional. If this is somehow unclear in the spec, we should clarify in the spec.

As far as the test failure, one question that really needs to be answered is whether the device actually RESPONDS to the appropriate subtypes even if it fails to list them in the service enumeration. If this is just a service enumeration issue, then perhaps we can adjust the test because the RFC is a LITTLE fudgy there on what's required. If they are not listed in the service enumeration because the device is not responding, then that is a different problem and that's what needs fixing.