I have run into that a few years back where if you put any entry in /etc/hosts you lose the network. It has been too long what really caused it but it seems like 2 different network mangers installed at the same time.
I use the minimal arm image.
I did not installed any additional network manger
Only dhcpcd
BTW, I have Pi-hole running as DHCP Server and DNS. On another raspberry pi.
Update:
I added the rpi3plus to my .ssh/config now.
if you use DNS and DHCP, did you configure them to assign hostnames, i.e., based on MAC address? If so, maybe remove the entry ārpi3lusā entry from etc/hosts and leave the name management to DNS. Seems @Darksky has the right idea.
Depends, do you have a DNS Server that is not the main DNS Server for your Network that can resolve your hostname? Do you have a search domain for your Network?
You need to configure your DNS Server in your network, so it āknowā the devices. This usually wont work out of the box. Specially if you use your own DHCP Server.
An alternative would be mDNS, but this needs Avahi on all Linux systems (and an open Port) and is not that fast. It uses ā.localā as a domain. Do not use this domain as your normal home network domain. It is reserved for mDNS.
The problem with a DNS lookup issues has nothing to do with the software use on your āraspberry piā, but only with the DNS setup on the system you ran the ping commands and the DNS setup of your Network.
However, if you use dhcpcd as a DHCP client on your āraspberry piā, make sure it sends the desired hostname with the DHCP queries. By default it is the hostname of the system.
Just install avahi on the rpi - then enable the avahi-daemon and the avahi-dnsconfd - same on your workstation
For unknown reasons my manjaro-arm minimal didnāt setup the hosts which may cause interference but using avahi I can ping it using the host name
$ ping rpi
PING rpi (172.30.30.102) 56(84) bytes of data.
64 bytes from rpi.local (172.30.30.102): icmp_seq=1 ttl=64 time=0.222 ms
64 bytes from rpi.local (172.30.30.102): icmp_seq=2 ttl=64 time=0.217 ms
64 bytes from rpi.local (172.30.30.102): icmp_seq=3 ttl=64 time=0.223 ms
64 bytes from rpi.local (172.30.30.102): icmp_seq=4 ttl=64 time=0.221 ms
64 bytes from rpi.local (172.30.30.102): icmp_seq=5 ttl=64 time=0.281 ms
64 bytes from rpi.local (172.30.30.102): icmp_seq=6 ttl=64 time=0.233 ms
If you are running an rpi on manjaro-arm minimal - then you would have setup a static ip - right?
Although it will work without - when you setup a such remote system - best practise is to remember populating the serverās /etc/hosts like
I should say that the client where I execute the ping is a Macbook.
Debian (Raspbian) ping works on the mb via ping hostname.
On ArchLinux ARM I do not have this issue, maybe config is different?
Otherwise it is a Pi-hole issue. IP of the Raspberry with manjaro has hostname āunknownā
I know that a lot of people has gotten used to various tools abstracting the intricasies of network but even those tools cannot find what is not configured correct.
But that does not make the command correct
ping rpi
whereas a FQDN is easily found
ping rpi.local
Perhaps - I can easily reproduce the issue using a macbook device.
But we are talking network configuration here so if one is not able to lookup a host - then - at some point - it is the configurattion which is at fault.
A properly configured hosts file is necessary if you want the device to be recognized by the network.
Using ping hostname is bound to give errors when the command requires a FQDN to be able to locate the host by traversing the name backwards e.g.
ping sql.net.nix.dk
but if there is no local authoritative nameserver for net.nix.dk if will end at nix.dk thus returning NXDOMAIN
You donāt have to use the big bind setup - as you could use unbound to run a few local-zone with a few hosts.
Avahi is authoritative for .local - but it needs to be configured.
Summary
fh@Root13 ~ % ping ns.net.nix.dk
PING ns.net.nix.dk (172.30.30.4): 56 data bytes
64 bytes from 172.30.30.4: icmp_seq=0 ttl=64 time=10.423 ms
64 bytes from 172.30.30.4: icmp_seq=1 ttl=64 time=5.235 ms
64 bytes from 172.30.30.4: icmp_seq=2 ttl=64 time=5.268 ms
64 bytes from 172.30.30.4: icmp_seq=3 ttl=64 time=202.344 ms
64 bytes from 172.30.30.4: icmp_seq=4 ttl=64 time=57.170 ms
^C
--- ns.net.nix.dk ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.235/56.088/202.344/75.691 ms
fh@Root13 ~ % dig rpi
; <<>> DiG 9.10.6 <<>> rpi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50324
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rpi. IN A
;; AUTHORITY SECTION:
. 10757 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023072400 1800 900 604800 86400
;; Query time: 14 msec
;; SERVER: 172.30.30.4#53(172.30.30.4)
;; WHEN: Mon Jul 24 15:36:27 CEST 2023
;; MSG SIZE rcvd: 107
fh@Root13 ~ % dig rpi.net.nix.dk
; <<>> DiG 9.10.6 <<>> rpi.net.nix.dk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26097
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rpi.net.nix.dk. IN A
;; AUTHORITY SECTION:
net.nix.dk. 3600 IN SOA ns.net.nix.dk. root.nix.dk. 2022040401 3600 3600 604800 10800
;; Query time: 12 msec
;; SERVER: 172.30.30.4#53(172.30.30.4)
;; WHEN: Mon Jul 24 15:36:32 CEST 2023
;; MSG SIZE rcvd: 87
fh@Root13 ~ % nslookup tiger
Server: 172.30.30.4
Address: 172.30.30.4#53
Name: tiger.net.nix.dk
Address: 172.30.30.20
fh@Root13 ~ % nslookup rpi.net.nix.dk
Server: 172.30.30.4
Address: 172.30.30.4#53
** server can't find rpi.net.nix.dk: NXDOMAIN
fh@Root13 ~ %
fh@Root13 ~ % nslookup rpi
Server: 172.30.30.4
Address: 172.30.30.4#53
** server can't find rpi: NXDOMAIN