On 28/04/2025 20:31, tomas@tuxteam.de wrote:
On Mon, Apr 28, 2025 at 01:12:17PM +0000, mailinglists.accustom994@aleeas.com wrote:On Monday, April 28th, tomas@tuxteam.de wrote:At some point, it'd been interesting whether yours were IPv4 zeroconf "link-local" addresses, i.e. in the 169.254.0.0/16 range: I'd bet they are :-)ip -c a does 192.168.x.x, soI won ;-)
mDNS may work without link-local 192.168.x.y addresses. Perhaps 192.168.x.y addresses may be used without mDNS as well, e.g. with LLMNR. That is why I would consider avahi and avahi-autoipd as independent services. (Strictly speaking, we do not know whether these tools or other ones are responsible for multicast name resolution and assigning a link-local address.)
There is too much uncertainty in respect to network configuration. I am in doubts if 192.168.x.y address is assigned if e.g. DHCP client started by NetworkManager receives response fast enough.
On 28/04/2025 11:20, tomas@tuxteam.de wrote:
While it is a good idea to have tshark, we already *know* that the OP's machine
...
You don't fix a bike by heaping tools on it 🙂
tcpdump output for *mDNS* requests (not for ICMP) may be helpful.In another branch of this thread "dig" was suggested. It sends DNS, not mDNS requests. mdns4_minimal depends however on a test DNS query. As to mDNS queries,
getent hosts h$RANDOM.local
Or perhaps even (untested since systemd-resolved is responsible for mDNS
on my machine)
getent -s mdns4_minimal hosts h$RANDOM.local
I recommend to the topic starter to read docs (on mDNS in general and
README files from packages in particular) and logs. It is a way when
privacy is crucial. Severely stripped and redacted output of commands
adds enough obstacles.