Open w8floosh opened 3 months ago
chip-tool calls into the DNS-SD library involved (which in this case seems to be the one based on Avahi) and all it gets back is whether results appeared or not.
If the Linux Avahi-based impl can detect that Avahi is not actually functional, it could try to log that. Not sure what the situation looks like there in this case.
You can see the relevant code in src/platform/Linux/DnssdImpl.cpp
and could experiment to see what information is available where in that code.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Remove stale label or comment or this will be closed in 30 days.
Reproduction steps / Feature
I recently stumbled upon a problem of mDNS resolution timeout in operational service discovery, using chip-tool.
Line 1102 of this chip-tool log shows an operational discovery failure with timeout, which is exact but really not explanatory of what actually happened.
In this case, I had the mDNS service blocked by my firewalld, thus preventing any multicast DNS operation on the machine, but I didn't understand this was the issue until I tried to get a service list from
avahi-browse -a
, resulting in no output, which can occur when the 5353 port is closed.I agree this outcome may be trivial (I shouldn't have assumed to have the service enabled on my machine), but it might be useful to let the logs better point out what the actual problem is, writing a more specific error (or errors, other scenarios may occur) to make the situation more readable to newcomers, instead of defaulting to timeout.
Let me know what do you think about that and if such deeper logging might be even possible.
Platform
other
Platform Version(s)
No response
Type
Manually tested with SDK
(Optional) If manually tested please explain why this is only manually tested
I'm learning how to use the SDK and chip-tool to better understand the protocol workflow
Anything else?
No response