no worrys bazzite is a “gaming” iso that tahts tryes to imitate steam os, and the issue was and is since i installed the os that my browser chrome cant open .local everthing else works.
and for on my other os windows it still works and yes the same maschine has 2 OS on it there on seperate drives just so you know
Maybe it simply lacks a mDNS client, like avahi.
I’m sorry, but you know, I spent some time today researching your responce. I can’t find any real evidence of setting a host entry, and that corrupting mDNS, and then requiring shutting down the entire network to resolve. Maybe if the entry was boink’d from the get-go. So maybe that is just your experience, in a much different environment, and what you may have experienced may not apply to this issue, or my suggestion at all.
It does seem, however, that many agree that Micrsoft’s implementation of mDNS (since stopping the use of Bonjoure) is less than steller. Linux Avahi and mDNS seems quite functionaly and highly configurable (see my thirdlink below). mDNS was developed from DNS, operates on just about all the same mechanics, and are compliant on most of the same record resources type, etc etc. See the first link, section 19.
I’m not going to hash it out further, as it’s beyond the scope of this question, but I’ll leave you with some links. It’s not as rigid or sensitive as you indicate.
DNS and mDNS are practically the same, conforming to the same standards, Here is the RFC.
Nice writeup of mDNS and basic function. I found the process one would think prevents coruption, unless something else is going on.
This is the coolest one. How to actually use mDNS as a sort of DNS replacement, which would highlight is flexibility. It also discusses the RFC a bit.
So, without any changes, can you open up a terminal session and type:
nc -zv homeassistant.local 8123
Do you get something like the following?
$ nc -zv homeassistant.local 8123
Connection to homeassistant.local (10.0.110.163) 8123 port [tcp/*] succeeded!
From Multicast DNS - Wikipedia
By default, mDNS exclusively resolves hostnames ending with the
.localtop-level domain. This can cause problems if.localincludes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid.
The shutting down is the standard way to clear an error in a series network, where entry lists are copied among participating members.
On the machine (linux) that has the resolve issue use the following:
$ sudo systemctl status avahi-daemon.service
Look for something similar to below with running
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2024-12-08 06:31:21 EST; 4h 34min ago
TriggeredBy: ● avahi-daemon.socket
Main PID: 1240 (avahi-daemon)
Status: "avahi-daemon 0.8 starting up."
Tasks: 2 (limit: 76243)
Memory: 1.4M
CPU: 4.371s
CGroup: /system.slice/avahi-daemon.service
├─1240 "avahi-daemon: running [pappy.local]"
└─1288 "avahi-daemon: chroot helper"
$ sudo avahi-browse -a -t
You should see the advertised local services, and hopefully one is homeassistant:
+ enx607d092638e7 IPv4 Kiwi _meshcop._udp local
+ enx607d092638e7 IPv4 Kiwi _srpl-tls._tcp local
+ enx607d092638e7 IPv4 Kiwi _trel._udp local
+ enx607d092638e7 IPv4 Kiwi _companion-link._tcp local
+ enx607d092638e7 IPv4 3623F3C5C821@Kiwi AirTunes Remote Audio local
+ enx607d092638e7 IPv4 Kiwi AirPlay Remote Video local
+ enx607d092638e7 IPv4 70-35-60-63.1 Kiwi _sleep-proxy._udp local
+ enx607d092638e7 IPv4 Home _home-assistant._tcp local
+ enx607d092638e7 IPv4 46DEA101AC611C75-000000005D0871CF _matter._tcp local
+ enx607d092638e7 IPv4 8D19B452A14C3405-00000000B2C7630A _matter._tcp local
+ enx607d092638e7 IPv4 Hue Bridge - 21CE80 _hue._tcp local
+ enx607d092638e7 IPv4 987C8B99ACE91526-000000000001B669 _matter._tcp local
+ enx607d092638e7 IPv4 homeassistant [465268e21b594f26883e7cc93341604b] Workstation local
You can then try any/all of the following:
$ sudo avahi-resolve -n homeassistant.local
The -n is resolve by name (homeassistant.local)
homeassistant.local 10.0.110.163
$ sudo avahi-resolve -a 10.0.110.163
The -a is resolve by address.
10.0.110.163 homeassistant.local
Is all these give the expected results, then its something with the browser.
If none can be found, avahi may not be installed or is now misconfigured.
If your system is using only systemd-resolve, and it’s configred to handle mDNS then avahi may not even be installed. I use Pop OS, which is an Ubuntu-based. It uses both, but mDNS is disabled in the systemd-resolve, so ahahi handles that part.
If that is the case, you can try the following as well.
resolvectl query homeassistant.local
Hope this helps you some.
so i tryid it in the linux konsole and everthing seems to working regarding avahi wich i installed because i tryit fixit that way, but the last command gives me a error
ZEROX@bazzite:~$ resolvectl query homeassistant.local
homeassistant.local: resolve call failed: No appropriate name servers or networks for name found
so im guessing there is a os config i have to change so taht i can resolve the .local adresses wich idk how completly new to linux
If the avahi -a (or -n) commands worked, then the message you received with the last command would give you an error. So It would seem to me that your browser is now the culprit.
In your browser, when you type
Does the browser try to redirect you to “https” by any chance?
I know my some of my browsers are configured to only allow me to https, so they will change (redirect) from http to https
1 Like
This is 100% accurate and the word you’re looking for is WILL and why the browser vendors are pushing.
(Its the #1 cause of 'I know xyz is listening to my - insert device with speaker - here.
No, someone from your IP address searched x and went to website y while having that conversation and the isp is hardwired into the ad platform selling the data near real-time as a revenue stream)
no it doesnt
1 Like
So I found an old article, with a similar Windows issue. It’s kinda funny, as the answer marked as solving the issue was what I suggested you do earlier… host file entry. LOL
My Chrome is pretty much stock install, but I reset the settings anway, and it works. If I leave the .local off the URL, it givens an NXDOMAIN (no/empty responce). So maybe you should just try to reset the browser.
I did find one note to try first though… one of the commenters mentioned that if you place a “/” after the port, this will cause Chrome to bypass it’s search, and just go straight to the URL. You could try that.
Another thing you might try is this (because I’m just curious if Chrome handles the search differently in the flags.) Goto
chrome://net-internals/#dns
Then enter homeassistant.local and see if it actually resolves the IP.
Good luck!
I appreciate the link, and understand the point you are making. And you are correct that it could create an issue. But the fact is, many MANY sysadmins use/do it (especially when working on headless services), and I don’t think there is any real problems using it, if done in the right manner, and one cleans up afterwards properly.
I felt for this particular point in time, he had nothing to fear, and no damage would be caused. I was just tryig to help him generate a different outcome, for troubleshooting.
Thanks again!
so just to make sure its not a chrome specicif issue i installed firefox and it too cant use .local adresses mind dm me to see if we can fix that using discord?
Just as an informational note, as xan mentioned above, this failure could be due to your linux distribution not having resolve configured to handle mDNS. One way to check is to look at /etc/systemd/resolved.conf and see if LLMNR is set to “no” or “yes”. In my case on Ubuntu, it is set to “no” and I get the same failure as you because of it.
1 Like
i dont see a resolve.config there should i add one? maybe that would fix it?
Try this to see if LLMNR is active on the interface:
$ sudo resolvectl status
You should see your active interface (mine is Link 3 currently) and the +LLMNR is active. Now this command is for systemd-resolve, and in my configuration mDNS is bening handled by my Avahi.
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 3 (wlo1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: x.x.x.x
DNS Servers: x.x.x.x
ZEROX@bazzite:~$ sudo resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eno1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: X.x.x.x
DNS Servers: x.x.x.x
DNS Domain: fritz.box
Link 3 (wlp7s0)
Current Scopes: none
Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
I would NOT recommend adding this file, there are other config files that may be used by resolved and are these are often maintained, managed by other subsystems.
[Edit] I should add that the reason that LLMNR is set to “no” is in order for avahi to handle mDNS instead of resolved.
1 Like
Thank you! I was going to append my last response with the fact that while my results show that LLMNR is configured, there is no actual listner on port 5355. It’s disabled at the service level.