For some time now I’ve been having problems with incorrect PTR entries in the Fritzbox. I think it’s been since IPv6 was activated because of experiments with Matter. In addition to the correct PTR entry (openhab), there is also a PTR entry like 192-168-100-100.
It looks like the openHAB mDNS service is the culprit. When I scan the network with avahi-browse, I see a service called _openhab-server._tcp local. This service displays the wrong hostname instead of openhab. As I can see with openhabian-config or hostname or hostnamectl, the hostname is correctly set to “openhab”.
If I stop the service “org.openhab.core.io.transport.mdns” in karaf console, then the service _openhab-server._tcp local disappears (as I can see with avahi-browse) and also the incorrect hostname. When I restart the service “org.openhab.core.io.transport.mdns”, the incorrect hostname immediately reappears.
As far as I can see, everything works because I use fixed IP addresses in my smart home. But this problem triggers my inner perfectionist
Is there a setting somewhere to configure the behavior of the mDNS service so that the hostname appears as “openhab” and not “192-168-100-100”?
The configured hostname and “mDNS hostname” isn’t the same thing. I don’t know why 192-168-100-100 is created, but I assume that it comes from the IP address?
Bindings can register “services” that are announced with the help of org.openhab.core.io.transport.mdns, I don’t think that bundle itself creates any service definition.
The only thing in core that I can find that creates an entry is org.openhab.core.io.rest.mdns, and the hostname it uses defaults to openhab, but it looks like it’s possible to make it something else by configuring a setting called mdnsName (somewhere, not sure where). Try to stop that bundle and see what disappears. If it’s the “right name” and the “wrong name” remains, then it’s done by a binding. If the “wrong name” disappears, you might need to look if mdnsName is configured somewhere.
That said, there are rules for mDNS hostnames. Duplicates aren’t allowed, so services that try to register must find a “free name”. What you see could be the result of this, that if openhab has already been grabbed by something else, something is made up using the IP address.
When I stop org.openhab.core.io.rest.mdnsnothing happens, the wrong hostname still remain.
Only when I stop org.openhab.core.io.transport.mdns the wrong hostname disappiers.
I found this in bundles/org.openhab.core.io.transport.mdns/src/main/java/org/openhab/core/io/transport/mdns/internal/MDNSClientImpl.java
private void createJmDNSByAddress(InetAddress address) {
try {
JmDNS jmdns = JmDNS.create(address, null);
jmdnsInstances.put(address, jmdns);
logger.debug("mDNS service has been started ({} for IP {})", jmdns.getName(), address.getHostAddress());
} catch (IOException e) {
logger.debug("JmDNS instantiation failed ({})!", address.getHostAddress());
}
}
@Override
public void onChanged(List<CidrAddress> added, List<CidrAddress> removed) {
logger.debug("ip address change: added {}, removed {}", added, removed);
close();
start();
}
}
I think I try to set the org.openhab.core.io.transport.mdns to debug or trace to see what happens when the bundle attempts to obtain the hostname.
It probably just means that org.openhab.core.io.rest.mdns doesn’t clean up after itself when shut down. Try to stop org.openhab.core.io.rest.mdns and leave it stopped, and then restart org.openhab.core.io.transport.mdns and see if it still registers the “wrong” name.
org.openhab.core.io.transport.mdns provides two “services”, MDNSService and MDNSClient. MDNSClient is only used for looking up/retrieving information about other participants, it doesn’t “register” anything. MDNSService is the one of interest here, because it is used when you want to announce that you provide a “mDNS service”, which includes a host name. One device can provide multiple services using multiple “host names”.
When I leave org.openhab.core.io.rest.mdns stopped then every time when I stop org.openhab.core.io.transport.mdns the wrong hostname PTR (192-168-x-x) disappears and when I start org.openhab.core.io.transport.mdns (org.openhab.core.io.rest.mdns still stopped) after a view seconds the wrong hostname PTR appears.
I think I’ll use tcpdump and openHAB logs next weekend to see what happens when org.openhab.core.io.transport.mdns is startet and stopped.
I don’t want to rule out the possibility that there might also be an error in the configuration of the avahi-daemon.
But I think JmDNS should use “openhab” as the hostname and not “192-168-x-x”.
Yes, but did it impact the registration of the “right” host name, openhab.
As I said before, that’s not quite how it works. Any part of OH, a binding for example, can make org.openhab.core.io.transport.mdns register a mDNS record on their behalf. So, it’s not neccesarily “OH”, and certainly not JmDNS that triggers this registration. If, as it now looks, org.openhab.core.io.rest.mdns isn’t the one registering it, I think it’s likely that one of your bindings does.
Sorry if I’m a bit slow on the uptake, but my native language is German and my English could be better
I think I know what you mean now. If I terminate org.openhab.core.io.transport.mdns, I only eliminate the effect because the process cleans up and the incorrect hostname then disappears. But the cause itself may lie in a binding. Is that what you mean?
But the question is, does the binding decide which hostname belongs to the IP address, or does the global JmDNS do that?
The script outputs the correct hostname “openhab” and not “192-64-x-x”.
I’ve read that there are occasional problems with the combination of avahi-daemon and JmDNS. Perhaps that’s the problem in my case.
As I said before, I will try to see more details using tcpdump, avahi-browse and openHAB logs.
Yes. org.openhab.core.io.transport.mdns is only the “messenger”, the service doing the registration on behalf of something else.
The binding (or whatever registers) decides what name to register. There is no relation to the “OS hostname” at all, the mDNS hostname can be anything.
Yes, but it has nothing to do with this. These are completely independent “hostname” concepts.
Avahi indeed does a lot of strange things, and I typically don’t run it. But, I don’t think it’s likey that avahi is to blame here - in fact, as far as I can tell, there’s nothing “wrong”, it’s just something that registers a name that “you don’t like”
I think I’m starting to understand how everything fits together. But where does the hostname of the _openhab-server._tcp service come from?
As far as I know, this service is used by openHAB to announce the local hostname under which openHAB can be reached. And why does it say “192-168-x-x.local” for the hostname and not “openhab.local”?
I can see this with avahi-browse when I inspect the services:
= enp2S0 IPv4 openhab _openhab-server._tcp local
hostname = [192-168-x-x.local]
address = [192.168.x.x]
port = [8080]
txt = [uri=/rest]
I don’t quite understand the connection. Is openHAB reporting the hostname correctly and the avahi-daemon misinterpreting something, or is openHAB reporting the hostname incorrectly?
I think I first need to learn how mDNS works in order to properly understand the connections
It’s unlikely that avahi “misinterprets” what is registered, something in OH is probably registering this hostname. But, is that the only registration made by OH? I thought you said earlier that it also registers openhab?
One device/application can register any number of mDNS services, using different hostnames. There is nothing that prevents it from registering more than one. That said, txt = [uri=/rest] indicates that org.openhab.core.io.rest.mdns is the “entity” behind the registration. And as I said above, when checking the source code, it does use openhab as the default hostname, unless a setting called mdnsName is configured to something different.
openhab is registerd by DHCP and avahi-daemon.
If mDNS is disabled in openHAB, then I can see, with dig -x [IP Adresse], a PTR record for the IP address with “openhab” as the hostname.
If mDNS is enabled in openHAB, then in addition to this PTR entry I also have a PTR entry with “192-168-x-x”
As I mentioned above, next weekend I will try to narrow down the error and look into mDNS in more detail.
Thank you so much for the information so far, and thank you for your patience
