Announcing DNS name on uPnP (for webif)

[af123]

I've uploaded it to https://hpkg.tv/hdrfoxt2/src/mdns.tar.gz

 

[/df]

Apparently a race condition in an unusual test scenario could lead to gethostbyname() failing.

 

[/df]

...Also, as this is the designated package thread, here are some other issues.

And in this repository branch is a quite a pleasing reworking of the mdnsd server that fixes them, avoiding the need to modify the S80mdnsd script. I've taken advantage of other modified versions of tinysvcmdns that implemented missing server functions and also fixed the known issues; source versions are in other branches.

The idea is to listen for answers from other devices and write each IP address <- host mapping as a line in /tmp/hosts, which through the magic of CF is used for local name resolution; static entries (that don't have .local suffixes) in /tmp/hosts are preserved. This allows things like ping humax2.local from humax1, and should also support entering .local names for NFS, etc.

The server reinitialises when it detects that the local IP address has changed. The local host, say "myhost", is recorded as both myhost and myhost.local, but only the latter is "advertised". That was quoted because what actually happens is that a long-lived authority (NSEC) record is advertised together with a short-lived A record; after that expires other hosts resolve the advertised hostname by querying.

There's a working (built on-box, stripped) binary in the sbin folder of the linked repository branch.

Although my Debian-derived PCs send a lot of mDNS stuff, they don't seem to show up as hosts. That's another problem.

 

[/df]

Example modinit.log extracts:

...
    Fri Jul 24 08:58:30 UTC 2020 - S80mdnsd (elapsed: 0s)
...
=== Fri Jul 24 08:58:41 UTC 2020 - setup hosts ===========================
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.0       0.0.0.0         255.255.255.0   U     0      0        0 wlan0
    Interface: [wlan0]
    IP: [192.0.2.200]
=== Fri Jul 24 08:58:42 UTC 2020 - complete ===========================
=== Fri Jul 24 08:58:42 UTC 2020 - modinit - setup_hosts ===========================
=== Fri Jul 24 08:58:43 UTC 2020 - setup hosts ===========================
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.254  0.0.0.0         UG    0      0        0 wlan0
    Interface: [wlan0]
    IP: [192.168.1.24]
=== Fri Jul 24 08:58:43 UTC 2020 - complete ===========================
...
Hostname: humax1 (192.168.1.100)
Registered name.
Hostname: humax1 (192.168.1.24)
Registered name.
Host 0: humax2.local (192.168.1.23)
Host 1: CanonPrinter.local (192.168.1.100)
Host 0: humax2.local (192.168.1.23)
Host 1: CanonPrinter.local (192.168.1.100)
Host 0: humax2.local (192.168.1.23)
Host 1: CanonPrinter.local (192.168.1.100)
...

 

[/df]

...
Although my Debian-derived PCs send a lot of mDNS stuff, they don't seem to show up as hosts. That's another problem.

My new mdnsd is looking for hosts offering HTTP service (_http.tcp.local). Obviously, the anonymous hosts are not doing that and certainly not advertising it, but as a workaround for machines running the Avahi mDNS daemon, you can drop a file named DummyHTTP.service (the extension is mandatory) into /etc/avahi/services, like so:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h-DummyHTTP</name>
<service protocol="ipv4">
<type>_http._tcp</type>
<port>0</port>
<txt-record>info=Dummy service for mDNS name resolution</txt-record>
</service>
</service-group>

 

[/df]

My current build uses mDNS only.

Should we still be handling LLMNR? It seems that the only Windows version in current support that doesn't have mDNS is 8.1.