Hi all,

I recently installed Debian on my old desktop, before this it was running Ubuntu. So my issue is before installing debian I was able to ping me other machine using ```ping hostname.local```, but after installing debian 12 I am not able to do that. I am
not expert in computer so kindly help me. If you guys need more info then please ask me as I don't know all the networking stuff.

OS: debian 12.10 [updated]

```avahi-daemon``` is installed, and running.

```libnss-mdns``` is also installed. nss-lookup.target is inactive though. And As I tired to start it through systemd there was a error which read.

Failed to start nss-lookup.target: Operation refused, unit nss-lookup.target may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status nss-lookup.target' for details.

There is already a line in /etc/nssitch.conf

hosts: files mdns4_minimal [NOTFOUND=return] dns

systemd-resolved is not installed.

relevant article

https://wiki.debian.org/Avahi

https://wiki.archlinux.org/title/Avahi

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Sorry I didn't mentioned output in my previous mail. This is output I get when I ping other machine:

ping: [hostname].local: Name or service not known. where [hostname] is a placeholder.

Thanks.

On Sunday, Andy Smith - andy@strugglers.net wrote:

Hi,

On Sun, Apr 27, 2025 at 11:24:25AM +0000, mailinglists.accustom994@aleeas.com wrote:

my issue is before installing debian I was able to ping me other
machine using `ping hostname.local`, but after installing debian
12 I am not able to do that.

Nowhere in your email have you shown to us or described to us what
actually happens when you try to ping one of your other machines.

We can't begin to help without you doing that. Once you've done that
there will likely be further questions, but that's where we start.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Apr 27, 2025 at 11:24:25AM +0000, mailinglists.accustom994@aleeas.com wrote:

my issue is before installing debian I was able to ping me other
machine using ```ping hostname.local```, but after installing debian
12 I am not able to do that.

Nowhere in your email have you shown to us or described to us what
actually happens when you try to ping one of your other machines.

We can't begin to help without you doing that. Once you've done that
there will likely be further questions, but that's where we start.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Apr 27, 2025 at 10:09:34AM -0400, Eben King wrote:

On 4/27/25 09:57, mailinglists.accustom994@aleeas.com wrote:

ping: [hostname].local: Name or service not known. where [hostname] is a placeholder.

Is [hostname].local in /etc/hosts or otherwise findable by DNS?

Okay so I see why OP was saying so much about mdns and avahi. The .local hostnames are meant to be autodiscovered, not present in hosts file or
DNS as such, and that's what the mdns4_minimal is for in
/etc/nsswitch.conf.

Unfortunately I never use mdns so I can't be of any further help
debugging, just wanted to steer this away from /etc/hosts and an actual
DNS server.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

No, [hostname].local is not in /etc/hosts, So does in ubuntu machine. As far as I know avahi should be resolving these.

Thanks

On Sunday, April 27th, Eben King - eben@gmx.us wrote:

On 4/27/25 09:57, mailinglists.accustom994@aleeas.com wrote:

Hi,

Sorry I didn't mentioned output in my previous mail. This is output I get when I ping other machine:

ping: [hostname].local: Name or service not known. where [hostname] is a placeholder.

Is [hostname].local in /etc/hosts or otherwise findable by DNS?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 27, 2025 at 09:30:43AM -0600, Charles Curley wrote:

On Sun, 27 Apr 2025 13:57:55 +0000
mailinglists.accustom994@aleeas.com wrote:

Sorry I didn't mentioned output in my previous mail. This is output I
get when I ping other machine:

ping: [hostname].local: Name or service not known. where [hostname]
is a placeholder.

No, no. Please show us *exactly* what you see, by copying from the
terminal [...]

I think by now it is quite probable that the OP is using mDNS and
that is not working. I'd suggest first checking whether there is
any link layer connectivity at all.

To the OP: please show us the output of the commands "ip addr show"
and "ip link show".

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA5RfgAKCRAFyCz1etHa RhCAAJ0TmxQ3M4pPgKu5daXlgdz+PzUGjACfb5Cre3XQMV8m2r2KS0wzx9edmH8=
=pPhP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 27 Apr 2025 13:57:55 +0000
mailinglists.accustom994@aleeas.com wrote:

Sorry I didn't mentioned output in my previous mail. This is output I
get when I ping other machine:

ping: [hostname].local: Name or service not known. where [hostname]
is a placeholder.

No, no. Please show us *exactly* what you see, by copying from the
terminal into your email. Please include the shell prompt, and the
following shell prompt so that we know where the output ended.
Something like:

charles@hawk:~$ ping snark.local
ping: snark.local: Name or service not known
charles@hawk:~$



--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 27 Apr 2025 17:47:19 +0200
<tomas@tuxteam.de> wrote:

On Sun, Apr 27, 2025 at 09:30:43AM -0600, Charles Curley wrote:

On Sun, 27 Apr 2025 13:57:55 +0000
mailinglists.accustom994@aleeas.com wrote:

Sorry I didn't mentioned output in my previous mail. This is
output I get when I ping other machine:

ping: [hostname].local: Name or service not known. where
[hostname] is a placeholder.

No, no. Please show us *exactly* what you see, by copying from the
terminal [...]

I think by now it is quite probable that the OP is using mDNS and
that is not working. I'd suggest first checking whether there is
any link layer connectivity at all.

To the OP: please show us the output of the commands "ip addr show"
and "ip link show".

That is the first step. I don't know how the installer works nowadays,
but I recall that long ago, if a non-expert installation didn't find a
DHCP server, it didn't install networking beyond localhost. So let's be
sure that networking is actually there first.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Here are the output of the cmnds that tomas suggested.

user@localhost:~$ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: [INTERFACE1]: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether [MAC1] brd ff:ff:ff:ff:ff:ff
altname [alt_interface]
3: [INTERFACE2]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [MAC2] brd ff:ff:ff:ff:ff:ff
inet [IP4]/24 brd [IP4] scope global dynamic noprefixroute [INTERFACE2]
valid_lft [TIME]sec preferred_lft [TIME]sec
inet6 [IP6]/64 scope global dynamic noprefixroute
valid_lft [TIME]sec preferred_lft [TIME]sec
inet6 [IP6]/64 scope link noprefixroute
valid_lft forever preferred_lft forever
user@localhost:~$

and second cmnd

user@localhost:~$ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: [INTERFACE1]: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether [MAC1] brd ff:ff:ff:ff:ff:ff
altname enp0s25
3: [INTERFACE2]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether [MAC2] brd ff:ff:ff:ff:ff:ff
user@localhost:~$

Hope that helps.

Thanks


On Sunday, April 27th, tomas@tuxteam.de wrote:

On Sun, Apr 27, 2025 at 09:30:43AM -0600, Charles Curley wrote:

On Sun, 27 Apr 2025 13:57:55 +0000
mailinglists.accustom994@aleeas.com wrote:

Sorry I didn't mentioned output in my previous mail. This is output I
get when I ping other machine:

ping: [hostname].local: Name or service not known. where [hostname]
is a placeholder.

No, no. Please show us exactly what you see, by copying from the
terminal [...]

I think by now it is quite probable that the OP is using mDNS and
that is not working. I'd suggest first checking whether there is
any link layer connectivity at all.

To the OP: please show us the output of the commands "ip addr show"
and "ip link show".

Cheers
--
t

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.04.2025 16:30 Uhr Andy Smith wrote:

Okay so I see why OP was saying so much about mdns and avahi. The
.local hostnames are meant to be autodiscovered, not present in hosts
file or DNS as such, and that's what the mdns4_minimal is for in /etc/nsswitch.conf.

mdns4 limits that to IPv4, try to replace that with just mdns.

--
kind regards
Marco

Send spam to 1745764201muell@stinkedores.dorfdsl.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.04.2025 16:30 Uhr mailinglists.accustom994@aleeas.com wrote:

No, [hostname].local is not in /etc/hosts, So does in ubuntu machine.
As far as I know avahi should be resolving these.

This is the case. Resolve should be done via mdns, which is handled by
Avahi.
Please use wireshark and sniff the traffic. Use a display filter for
mdns and check if the request goes out.

--
kind regards
Marco

Send spam to 1745764201muell@stinkedores.dorfdsl.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 27, 2025 at 04:56:26PM +0000, mailinglists.accustom994@aleeas.com wrote:

Hi,

Here are the output of the cmnds that tomas suggested.

Thanks for those. Another one which might be of interest
(I suggest you don't obfuscate the IP addresses; otherwise
it's on you to interpret them) would be

ip neigh show

This would tell you about "neighbours", i.e. other IP addresses
your machine has "seen" (technically IP addresses which have been
resolved to link-level addresses: ARP and that).

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA54aQAKCRAFyCz1etHa RmCIAJ9hyePc6dCXHw05C2h6iIHP1ovJJwCePgW/It+MnPpJ2HYx6t6EINUm3fo=
=tF49
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 28th, Timothy M Butterworth timothy.m.butterworth@gmail.com wrote:

Are you able to ping by IP address instead of host name?

Yes, I am able to ping other machines in LAN through IPs.

Are you able to resolve the DNS name with dig? dig hostname.local

NO, QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Thanks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 27, 2025 at 04:28:48PM -0400, Lee wrote:

On Sun, Apr 27, 2025 at 3:33 PM wrote:

Hi,

Here are the output of the cmnds that tomas suggested.

... with all the good stuff elided

Sad, but True

Hope that helps.

Not particularly.

Try this:

sudo apt install tshark
sudo tshark -f 'port 5353' -c 4 -N dnt &
ping -c 4 whatever.local

At least for me, it shows the mdns requests being sent and the answers received.

The good test again, now in two parts.
With minor changes and additional information.

Part one:

sudo apt install tshark


Part two:

sudo tshark -f 'port 5353 or icmp or arp' -N dnt &
ping -c 4 whatever.local
kill %1



Part one installs a network sniffer, it diagnostic software for
computer networking challenges, it shows what happens on the wire.
(On wireless network, it shows what happens in the ether.)


Part two is the interest part. It is "the intended ping" that
stops after a count of 4 ping attempts. Before the ping is start,
is `tshark` started in the background. It watches all network traffic
but the filter makes it showing only mDNS, ping related packets
and Address Resolution Protocol packages. The `kill %1` will stop
the first background job, most likely the tshark process.
Please be warned that there will much output on the terminal, it will
be hard to type the `ping -c 4 whatever.local` and `kill %1`.

Shared the screen content with the mailinglist.


Groeten
Geert Stappers

<screen_content from="my test" test="ping -c 4 alpaca">
stappers@paddy:~
$ sudo tshark -f 'port 53 or icmp or arp' -N dnt &
[1] 2667205
stappers@paddy:~
$ Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
1 0.000000000 48:d2:24:a5:cd:5e → 00:b0:d0:ed:73:57 ARP 42 Who has 172.24.0.10? Tell 172.24.0.36
2 0.002740520 00:b0:d0:ed:73:57 → 48:d2:24:a5:cd:5e ARP 60 172.24.0.10 is at 00:b0:d0:ed:73:57
3 0.235064745 00:b0:d0:ed:73:57 → 48:d2:24:a5:cd:5e ARP 60 Who has 172.24.0.36? Tell 172.24.0.9
4 0.235082414 48:d2:24:a5:cd:5e → 00:b0:d0:ed:73:57 ARP 42 172.24.0.36 is at 48:d2:24:a5:cd:5e
5 2.563991678 48:d2:24:a5:cd:5e → 00:b0:d0:ed:73:57 ARP 42 Who has 172.24.0.9? Tell 172.24.0.36
6 2.566194507 00:b0:d0:ed:73:57 → 48:d2:24:a5:cd:5e ARP 60 172.24.0.9 is at 00:b0:d0:ed:73:57
ping -c 7 12.142650250 24:65:11:a9:b5:43 → 48:d2:24:a5:cd:5e ARP 60 Who has 172.24.0.36? Tell 172.24.0.1
8 12.142666844 48:d2:24:a5:cd:5e → 24:65:11:a9:b5:43 ARP 42 172.24.0.36 is at 48:d2:24:a5:cd:5e
4 alpaca
PING alpaca.gpm.stappers.nl (172.24.0.9) 56(84) bytes of data.
64 bytes from alpaca.gpm.stappers.nl (172.24.0.9): icmp_seq=1 ttl=64 time=1.30 ms
9 30.264172394 172.24.0.36 → 172.24.0.10 DNS 93 Standard query 0xef0f A alpaca.gpm.stappers.nl OPT
10 30.265797294 172.24.0.10 → 172.24.0.36 DNS 109 Standard query response 0xef0f A alpaca.gpm.stappers.nl A 172.24.0.9 OPT
11 30.266161962 172.24.0.36 → alpaca.gpm.stappers.nl ICMP 98 Echo (ping) request id=0x0002, seq=1/256, ttl=64
12 30.267437559 alpaca.gpm.stappers.nl → 172.24.0.36 ICMP 98 Echo (ping) reply id=0x0002, seq=1/256, ttl=64 (request in 11)
13 30.268114471 172.24.0.36 → 172.24.0.10 DNS 94 Standard query 0x66be PTR 9.0.24.172.in-addr.arpa OPT
14 30.269635163 172.24.0.10 → 172.24.0.36 DNS 130 Standard query response 0x66be PTR 9.0.24.172.in-addr.arpa PTR alpaca.gpm.stappers.nl OPT
64 bytes from alpaca.local (172.24.0.9): icmp_seq=2 ttl=64 time=4.53 ms
15 31.268062754 172.24.0.36 → alpaca.gpm.stappers.nl ICMP 98 Echo (ping) request id=0x0002, seq=2/512, ttl=64
16 31.272567646 alpaca.gpm.stappers.nl → 172.24.0.36 ICMP 98 Echo (ping) reply id=0x0002, seq=2/512, ttl=64 (request in 15)
17 31.273216718 172.24.0.36 → 172.24.0.10 DNS 94 Standard query 0x66f7 PTR 9.0.24.172.in-addr.arpa OPT
18 31.275600004 172.24.0.10 → 172.24.0.36 DNS 130 Standard query response 0x66f7 PTR 9.0.24.172.in-addr.arpa PTR alpaca.gpm.stappers.nl OPT
64 bytes from alpaca.local (172.24.0.9): icmp_seq=3 ttl=64 time=4.10 ms
19 32.269495822 172.24.0.36 → alpaca.gpm.stappers.nl ICMP 98 Echo (ping) request id=0x0002, seq=3/768, ttl=64
20 32.273577761 alpaca.gpm.stappers.nl → 172.24.0.36 ICMP 98 Echo (ping) reply id=0x0002, seq=3/768, ttl=64 (request in 19)
21 32.274217422 172.24.0.36 → 172.24.0.10 DNS 94 Standard query 0x7301 PTR 9.0.24.172.in-addr.arpa OPT
22 32.324403220 172.24.0.10 → 172.24.0.36 DNS 130 Standard query response 0x7301 PTR 9.0.24.172.in-addr.arpa PTR alpaca.gpm.stappers.nl OPT
64 bytes from alpaca.local (172.24.0.9): icmp_seq=4 ttl=64 time=12.0 ms

--- alpaca.gpm.stappers.nl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.296/5.469/11.952/3.943 ms
stappers@paddy:~
$ 23 33.270798738 172.24.0.36 → alpaca.gpm.stappers.nl ICMP 98 Echo (ping) request id=0x0002, seq=4/1024, ttl=64
24 33.282729280 alpaca.gpm.stappers.nl → 172.24.0.36 ICMP 98 Echo (ping) reply id=0x0002, seq=4/1024, ttl=64 (request in 23)
25 33.283371940 172.24.0.36 → 172.24.0.10 DNS 94 Standard query 0x912d PTR 9.0.24.172.in-addr.arpa OPT
26 33.286218342 172.24.0.10 → 172.24.0.36 DNS 130 Standard query response 0x912d PTR 9.0.24.172.in-addr.arpa PTR alpaca.gpm.stappers.nl OPT
27 35.327995754 48:d2:24:a5:cd:5e → 00:b0:d0:ed:73:57 ARP 42 Who has 172.24.0.10? Tell 172.24.0.36
28 35.332714625 00:b0:d0:ed:73:57 → 48:d2:24:a5:cd:5e ARP 60 172.24.0.10 is at 00:b0:d0:ed:73:57
kil 29 37.375995228 48:d2:24:a5:cd:5e → 00:b0:d0:ed:73:57 ARP 42 Who has 172.24.0.9? Tell 172.24.0.36
30 37.381

On Sun, Apr 27, 2025 at 11:36:17PM +0200, Geert Stappers wrote:

On Sun, Apr 27, 2025 at 04:28:48PM -0400, Lee wrote:

On Sun, Apr 27, 2025 at 3:33 PM wrote:

[...]

Hope that helps.

Not particularly.

Try this:

sudo apt install tshark
sudo tshark -f 'port 5353' -c 4 -N dnt &
ping -c 4 whatever.local

At least for me, it shows the mdns requests being sent and the answers received.

The good test again, now in two parts.
With minor changes and additional information.

Part one:

sudo apt install tshark

Part two:

sudo tshark -f 'port 5353 or icmp or arp' -N dnt &
ping -c 4 whatever.local
kill %1

While it is a good idea to have tshark, we already *know* that
the OP's machine

- is trying to resolve via mDNS
- *that* part is failing.

... because:

- the interface link seems to be up and sees a connection
- They said pinging by IP works


So the next step would be to find out why mDNS is failing.
You don't fix a bike by heaping tools on it :)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA8B/wAKCRAFyCz1etHa RpLwAJ4mD/wu6K2CagNTQDowGYwO4ZXoIgCfSqvsQR58PavbScJT6BCid6+liyA=
=xxli
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mailinglists.accustom994@aleeas.com writes:

Hi all,

I recently installed Debian on my old desktop, before this it was
running Ubuntu. So my issue is before installing debian I was able to
ping me other machine using ```ping hostname.local```, but after
installing debian 12 I am not able to do that. I am not expert in
computer so kindly help me. If you guys need more info then please ask
me as I don't know all the networking stuff.

Do you have a firewall in any computer? mdns uses UDP port 5353 and that
would need to be allowed for it to work.

I've generally found mdns to be fairly unreliable, works sometimes and sometimes doesn't. Still, better to have it even as a flaky backup DNS
than no DNS, if actual DNS has issues or is unreachable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Apr 28, 2025 at 12:40:54PM +0000, mailinglists.accustom994@aleeas.com wrote:

On Monday, April 28th, tomas@tuxteam.de wrote:

While it is a good idea to have tshark, we already know that
the OP's machine

- is trying to resolve via mDNS
- that part is failing.

Yeah, Thanks for understanding. There are couple of connection like 0.0.0.0:mdns and [::]:mdns that I can see. I posted in this mailing list to know that whether are there some dependencies not satisfied or I have to check some conf files.

OK.

I should have been more clear, I guess. About redacted IPs and mac address, I am not sure I am comfortable posting my public IPs in a forum that is going to be archived. Don't get me wrong I willing to help you guys to help me. But I am not sure how

knowing exact ips are helpful. If you guys can tell what you guys are looking for, or share relevant links so that I can lookup.

That was my guess. By now I think it is irrelevant, since we
advanced to the mDNS issue. 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 :-)

Note that posting such (local, non-routable) addresses is pretty
harmless, since they won't be seen beyond your gateway, and many
of us have some of those at home ;-)

Now to the mDNS experts (I'm not one, mind you).

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA97AwAKCRAFyCz1etHa RtWCAJ4uJxEEQDSZmlZdMcXW1K9WnmMO5gCfe/UlWhgvM8xZLl1PQ2UlXCBu6gU=
=S1NA
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 28th, Anssi Saari - anssi.saari@debian-user.mail.kapsi.fi wrote:

Do you have a firewall in any computer? mdns uses UDP port 5353 and that would need to be allowed for it to work.

Yes, I have enabled firewall on both systems. But So was in the previous system, and mDNS used to work just fine. I will open and check port 5353, if that works.

I've generally found mdns to be fairly unreliable, works sometimes and sometimes doesn't. Still, better to have it even as a flaky backup DNS
than no DNS, if actual DNS has issues or is unreachable.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 28th, tomas@tuxteam.de wrote:

While it is a good idea to have tshark, we already know that
the OP's machine

- is trying to resolve via mDNS
- that part is failing.

Yeah, Thanks for understanding. There are couple of connection like 0.0.0.0:mdns and [::]:mdns that I can see. I posted in this mailing list to know that whether are there some dependencies not satisfied or I have to check some conf files.

I should have been more clear, I guess. About redacted IPs and mac address, I am not sure I am comfortable posting my public IPs in a forum that is going to be archived. Don't get me wrong I willing to help you guys to help me. But I am not sure how
knowing exact ips are helpful. If you guys can tell what you guys are looking for, or share relevant links so that I can lookup.

... because:

- the interface link seems to be up and sees a connection
- They said pinging by IP works

So the next step would be to find out why mDNS is failing.

Yeah that will be helpful.

You don't fix a bike by heaping tools on it :)

Cheers
--
t

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Apr 28, 2025 at 01:12:17PM +0000, mailinglists.accustom994@aleeas.com wrote:

On Monday, April 28th, tomas@tuxteam.de <tomas_at_tuxteam_de_emhokkkkd@simplelogin.co> wrote:

That was my guess. By now I think it is irrelevant, since we
advanced to the mDNS issue. 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 ;-)

Note that posting such (local, non-routable) addresses is pretty
harmless, since they won't be seen beyond your gateway, and many
of us have some of those at home ;-)

Yeah IP4 was local address but IP6 were global.

Indeed: if everything is working as it should, those are more
"interesting" (at least the ones not "fe80:...").

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA+DRwAKCRAFyCz1etHa Rg3XAJ975E+vxcP8tfEkzlHny+ZIH+lyWACeIg+z85L2Cf/bURAe5XwuUlOWw4U=
=eQX4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 28th, tomas@tuxteam.de <tomas_at_tuxteam_de_emhokkkkd@simplelogin.co> wrote:

That was my guess. By now I think it is irrelevant, since we
advanced to the mDNS issue. 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

Note that posting such (local, non-routable) addresses is pretty
harmless, since they won't be seen beyond your gateway, and many
of us have some of those at home ;-)

Yeah IP4 was local address but IP6 were global.

Thanks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Apr 28, 2025 at 10:32:26AM -0400, Lee wrote:

[...]

- is trying to resolve via mDNS

How do we know that? Has the OP sent you a private message showing
the mdns requests going out to the network?
If no then I would say we don't know if their machine is trying to do
mdns or not.

We have pretty strong giveaways:

- First message in this thread
Message-ID: <174575307036.7.10251064821870280516.695497701@aleeas.com>
From: mailinglists.accustom994@aleeas.com

Failed to start nss-lookup.target: Operation refused [...]

- Another:
Message-ID: <174576227925.7.18335587670536658966.695639660@aleeas.com>

From: mailinglists.accustom994@aleeas.com
ping: [hostname].local: Name or service not known.

Note the ".local" domain? *If* the OP had explicitly set that
up in a (heh) local DNS, I assume they would know. So pretty,
pretty sure it's zeroconf/mDNS.

- another:
Message-ID: <174576374522.6.17288671241541104876.695673548@aleeas.com>

[hostname].local is not in /etc/hosts

This rules out /etc/hosts: this leaves an explicitly set up DNS server
resolving the .local domain (see above), or mDNS.

I've got no farm, but I'd be willing to bet it on that :)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaA/PkgAKCRAFyCz1etHa Rjo2AJ9jgtrZTCjCzkhkVHaHx5agTgf8XACfc+I4pMieoBaLAJixYVP2LVmcwbo=
=gaUi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 29, 2025 at 10:06:05AM +0700, Max Nikulin wrote:

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, 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.)

Strictly speaking you are right, of course. But they tend to appear in
couples :-)

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.

Absolutely.

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.

Yes, but...

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

... very good points: I'd propose this to be the next steps.

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.

Thanks for your (very insightful, as always) comments!

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaBBUigAKCRAFyCz1etHa Rj1RAJsHZgBay87xaR50bv0FoLGStkZw3gCdG2J/boOUluid8uomdtsQczKebQg=
=QI4p
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)