On 28/04/2025 20:31, to...@tuxteam.de wrote:
On Mon, Apr 28, 2025 at 01:12:17PM +0000, mailinglists.accustom...@aleeas.com
wrote:
On Monday, April 28th, to...@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, so
I 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, to...@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.
