I have a bunch of Manjaro clients on my local network. All the clients can ping/ssh/etc using the host names that are set by the client (presumably provided by my router DNS service).
For example, client “rene” is able to be connected to just using “rene” from the other clients. e.g. “ssh rene” just works.
However, my main computer does not want to see the hostnames. I can’t ping them by their hostnames (unless I put an entry into my hosts file - which, while it works, is really not what I’d like to have to do with all the clients I need to connect to).
I originally assumed it was caused by Avahi, but that’s running on at least one other client and doesn’t seem to cause any problem for it. I’ve disabled the avahi service, since I don’t actually use it for anything, and that didn’t fix anything.
When I run nmap for the network, here’s an example from one of the working clients:
Nmap scan report for rene (192.168.1.129)
Host is up (0.00026s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
But from my non-working computer:
Nmap scan report for 192.168.1.129
Host is up (0.00049s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
Surely I changed some config to make this happen along the way, but I have no idea what. As far as I know, it’s always been this way since installing about a year or so ago on this computer.
Thoughts on how to troubleshoot this? I know just some basics of networking, not enough to really get anywhere. I’ve scoured Google and this forum, tried all kinds of things to no avail.
As I mentioned, Avahi was enabled before, and I disabled it.
Avahi did work for using hostname.local, but all the other Manjaro clients allow using just hostname (without .local). I’d like to do that - it’s a lot more efficient to type And I don’t have to try to remember which computer I’m on that works in what way, which can get confusing.
Is there a way to enable just plain hostname addressing from DNS just like on all the other clients? Surely there is, because my other Manjaro clients are doing it (by default?)
(By the way, I had Avahi enabled on one of the other clients, and it still just used the hostname without .local…so there’s something else at play regardless.)
I explained that I disabled it before; but to add to that:
It works perfectly without Avahi on all the other clients…
It’s easier to type without .local
I’d like to not have to remember which computer I’m on that needs the .local or not
I don’t have a reason for Avahi other than this; and if it can work (better, according to my needs) without it, why use it?
I’d like to understand better how the other clients work vs how this one works so that I can understand the way Manjaro DNS works better.
I’d really love if someone can help point me in the right direction for figuring out how this works and what’s different, if for no other reason than I’d like to solve this puzzle (though I also have the reasons given in 1-5).
Also, as I stated, I know that I can use /etc/hosts - but it’s a pain to put all of them in and keep the up-to-date.
Start with checking /etc/resolv.conf . It often indicate which software created the file in the first place. Compare the file on your different systems.
I don’t have systemd-resolved running on any of my Manjaro instances.
When ever I run into a network issue, I use NetworkManager to fix it. Or if I even try to set up something not even advanced, I have to use nmcli or the play in the /etc/NetworkManager/system-connections area.
Is the problem still that one instance doesn’t append domains to your host lookups?
We used to have to hardcode search example.com into resolv.conf back in the day, but even today, it’s still generated.
Even on mine:
cat /etc/resolv.conf
# Generated by NetworkManager
search hosenet.local
nameserver 10.2.4.1
But mine is set via my DHCP server (and router). I can see it set, when I: nmcli conn show "Connection Name"
(Which just lists all the properties.)
I would of guessed it would be in: ipv4.dns-search – But mine is empty.
I do have: IP4.DOMAIN[1] set with my domain though. (And mine does work.)
See what you have, and you could set it through: nmcli conn modify ConnName prop value
Ensure you have avahi-daemon.service and possibly avahi-dnsconfd.service running on all systems - the latter avahi-dnsconfd.service does not exist on all Linux breeds - it does on Manjaro Linux.
DNS is a complex subject and long time ago - approx 10y - I banged my head at a similar issue.
I was running Arch Linux at the time because I wanted to learn how to setup Linux - in detail
The way I did it - after many blind roads - was the bind road
I knew the .local was not the way - bad experience with being system admin for MS SBS networks - which forced the use of .local - with various certificate issues as a consequence.
The problem with selfmade local domains - e.g. .lan or .whatever - is the forwarding to upstream dns.
I was selfhosting everything - except dns - at the time I used a danish dns provider - which allowed me to create thirdlevel dns from my domain name.
So I created a SOA for my thirdlevel domain pointing to a local bind DNS service. The service is authoritative only and responds to queries for my local network.
My bind instance has zone file for my network and zone file for reverse lookup - and I have hostname lookup and fully qualified lookup for devices in my network.
I initially started my journey with my bind service providing all dns requests by doing recursive lookups using root servers.
This lead to the need of blocking ad and malware using bind response policy zone (RPZ)
Recently I changed that and deployed a pi-hole dns cache service and made my bind service responsible for my local network only.
I use raspberry pi SBC’s to run those services - the cost in power is neglible.
That is expected when you are using network manager.
Since you are using Network Manager - did you set the search domains on the IPv4 properties tab?
So…I’m confused that on a brand new Manjaro client everything works as expected (by me in this case), without those services, and when I start those services on this client, it doesn’t work as expected still…but you’re telling me that will solve the problem?
It won’t solve the problem regardless - as mentioned, I have tried this already, and it still behaves differently than the one client that DOES have Avahi service active (which returns the expected hostnames without .local appended.) So, even if I wanted to set up Avahi on all clients, and it did work making them all append .local so it was the same everywhere, it still wouldn’t work for that other client (at least), and I’d have a lot more overhead to deal with when trying to resolve other network problems.
I don’t understand why all the settings that I can find for all network configs are the same on all machines (while, obviously, knowing that I likely haven’t covered all configs, which is exactly the issue I’m trying to resolve here), but I have different behaviors.
I’d really like to know why that is — so I can have some actual control and understanding of my networking.
I’d love to just get help finding out where to look to see what is causing the different between clients which can (by default on a clean install) get the host names of all other clients on the network automatically, and the one computer which can’t.
No - the problem is that, by default (on a clean Manjaro client install) I can see/use the hostnames for all clients on the local network, which are provided by my router’s DNS without any domain; and this one client doesn’t do that, so I am trying to figure out why, so that I can make it work the same.
I’ve compared all the network related configs that I can find (based on google/forum searches) between the working and nonworking clients, and they all are the same. So I’m asking here so I can get suggestions as to where to look to troubleshoot this difference.
Since there are no obvious reasons for the different behavior, you need to dig a little deeper.
One possibility is to monitor network packages, so you see which technique is used. Or if you don’t see nothing at all. Wireshark can be used for this.
Also nmap is not a good tool to for debugging DNS. For example use nslookup form the bind package to check if any search domain is applied and if you see this different behavior. nslookup can only be used for DNS and not mDNS.
You can also compare running services on both machines and differences in installed packages.
Unfortunately, this is all not straight forward and may require a lot of work. I would start with Wireshark to check which network packages are send so you know exactly which technique is used. But if you never used Wireshark, it might not the easiest tool to learn.
I thought I said that. Still unsure if we are talking about the same thing.
This doesn’t resolve the FQDN on the DNS server. You tack on the domain locally.
Mine, and both yours set this on the dhcpd server (router), but it uses that to configure NetworkManager. At least it does by default for me.
Did you even look for the properties? (nmcli conn show "Connection 1") That’s where mine got set.
My FreeBSD router (and dhcpd server), I configured it to send out the search domains there. But the same NetworkManager property gets set. (Which in turn you see generated and showing on /etc/resolv.conf)
Ok, so I don’t know exactly what I’m looking for, here is the output. Doesn’t look like a different DNS server is being set here (is that what I’m looking for?):
Derp, I scrolled down and didn’t see more, but I apparently don’t have scroll fu as it looked like there wasn’t more than that. Thanks
So here it is compared to a “working” client (JUST installed Manjaro on it, made no changes to anything yet, it pings hostnames just fine), the only difference that mattered (apart from device addresses and names specific to the host device) I could see was this line:
ipv6.addr-gen-mode: stable-privacy
On the working client, it’s set to “default”. A quick googling didn’t seem to indicate that should matter. But I’m looking at what that does and whether it may affect this behavior and how to change it.
And I don’t have to try to remember which computer I’m on that works in what way, which can get confusing.