-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mDNS implementation questions. #10273
Comments
Thanks, @Cristib05. I'm surprised that cert tests mandate specific behaviors for additional record generation, as RFC 6763 frames these as recommendations. We intentionally omitted additional records for sub-type PTR browse queries to reduce message size and traffic. These queries usually aim to identify devices with a particular function and are often accompanied by a base type browse (which would include those records). We can modify the code to include additional records for sub-type PTR queries. I'll submit a PR for this shortly.
Regarding this, the service and host registration APIs in native mDNS are intentionally independent of each other. This design choice aligns more closely with how they are used by Advertising Proxy. Callers can first attempt to register the host before registering services under the same host name. |
@Abhayakara @EskoDijk , should we relax this check in the Thread Test Specification? |
But let me understand correctly: we register a service |
@jwhui @abtink The current 1.3 test plan does not mandate additional records to be generated (I checked R6). It may be that some of the test scripts aren't yet updated to R6 -> for that a TSTBED JIRA issue can be filed ; @radua-nxp can you do this? |
@Cristib05 is working on this! |
Describe the bug A clear and concise description of what the bug is.
Thread 1.3 Certification Test 2.15 is failing for the BR DUT on step 12 and all other steps related to a PTR query for a subtype.
It seems that the current native mDNS implementation is not adding any other RRs, except for subtype's specific PTR when answering for a subtype PTR query. Certification testing seems to be checking if the base service RR are present, a service name check seems to be performed.
A comparation has been done with dns-sd implementation:
Found out that in
Core::ServiceEntry::PrepareResponseRecords
is determined which RR should be added to the message.Would it be a bad idea that for a specific subtype PTR record that has to be added to an answer, the corresponding base SRV, TXT, AAAA records to be
MarkToAppendInAdditionalData()
. In this way, an mDNS browse from AIL will generate the same output as a DNS browse from OT side.Another issue that our team discoverd is that a service registration can be performed using an mDNS host that has not been previously verified unique on the network.
There was already an 'Ubuntu' host registered on the network in this case, but no error on registration.
Comparing to dns-sd implementation, it seems that a service registration using
dns-sd -R
, is adding the host to the Queries and also to the Authoritative section:In the current implementation, the service will be present when issuing
mdns services
, but the host is not. A simple browse query will result in:but the target is not reachable, a NSEC record will be issued for an AAAA query.
Services remain also present when a host in unregistered. Should those be deleted in those scenarios? What do you think?
To Reproduce Information to reproduce the behavior, including:
Expected behavior A clear and concise description of what you expected to happen.
Console/log output If applicable, add console/log output to help explain your problem.
Additional context Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: