[BUG] Chip-lighting-app with "minimal mdns" do not adhere to MDNS specs: Sends Multicast Truncated Responses #29521
Comments
Compiled how? Was this using minimal mdns or platform mdns? Also, the issue title is talking about chip-tool, but the actual description seems to be about chip-lighting-app. Which is it @Apollon77 ? |
|
Sorry to be inaccurate here. Ok I verified it. It is the "chip lighting app" taken from the certification binaries from Test Harness (so also not self compiled), last updated 16.9.23, so I can not tell how they are compiled ... When I see this output I would assume "minimal mdns" ... If it helps I can play around with these and macos "self build" ones and see what they report. |
Apollon77
changed the title
|
PS: A chip lighing app compiled on my macos seems to use platform mdns and behaves different |
Apollon77
changed the title
Apollon77
changed the title
Yes, that looks like minimal mdns. @andy31415 could you take a look, please? |
bzbarsky-apple
changed the title
|
I think truncation bit was on purpose, maybe I had mis-read the spec. |
|
The setting is here: https://github.com/project-chip/connectedhomeip/blob/master/src/lib/dnssd/minimal_mdns/ResponseSender.cpp#L310 //....
if (!mResponseBuilder.Ok())
{
mResponseBuilder.Header().SetFlags(mResponseBuilder.Header().GetFlags().SetTruncated(true));
ReturnOnFailure(mSendState.SetError(FlushReply()));
//...And can be easily removed, however since we had a few iterations on this I am concerned not to introduce some odd incompatibility issues. It seems we probably have to track unicast vs multicast replies here. |
|
I think one discussion is the 512 bytes because this is the "very old interprettion" ... there are also infos that 1500 - or when looking at IPv6 1280 are completely ok values ... when you then substract udp and ipv6 headers you end up in 1232 bytes pure payload that should work these days without any issue. I honestly do not know in which cases this is not acceptable. macos platform implementation is splitting it into several announcments:
2.) one with the matter specific records 3.) one again with hostname but only ipv6 ips 4.) one "big" (516 bytes) with all data together "lead" by TXT record 5.) And then again "anything" but without the TXT record :) So from that honestly ... no idea whats a best practice :-)) I stumbled over the sizing issue mainly because a device paired with 4 ecosystems ( I think when you use 512 bytes you already start to get those issues with the second or third device) went over size and so all throw away. SO when you decide for a "best practice" on how to split into packages it qwould be cool to get the infos and I will adjust matter.js implementation the same. |
|
Generally I assume mac does the right thing, however we probably have to test backwards compatibility with avahi and maybe others. Probably should do it right after a branch point to allow things to settle down. Things that we seem to want to adjust: usage of truncated, maximum payload size. |
|
I agree. Announcing host and rest separately makes sense - but why multiple times each a bit differently? ;-) (and that apple implementation always announce a hostname with just 0 is still strange but most likely different topic). If I can support in that topic just poke me ... whatever you implement I would also add then in matter.js the same way for our "own implementation" - but we also plan to add more native options like avahi via dbus or such platform |
That's because we never get a useful MAC address. Filed #29556 |
Reproduction steps
I checked via Wireshark what a chip lighting app does MDNS wise and found that a Truncated response is sent to annoucne itself because all data do not fit into the 512 byte of a single MDNS message.
According to MDSN specs this should not be used - see https://www.rfc-editor.org/rfc/rfc6762.html#section-18.5
This is the wireshark output of the announcements sent out:
First "Truncated" message:
Second "Finalizing" message:
The chip lighting app used here was run on a Raspi with Ubuntu.
Bug prevalence
always
GitHub hash of the SDK that was being used
can not reproduce, mid August 2023
Platform
other
Platform Version(s)
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: