Beta [zeroconf/mdnsd] Announcing DNS name on uPnP (v2 beta)


Well-Known Member
I wrote: this repository branch is a quite a pleasing reworking of the mdnsd server ...
To plug the repository gap, here's the latest package built from my source code (HummyNew branch), which has apparently been working well for me on three HDs and one HDR for a couple of months.

This version silently updates the existing mdnsd package without uninstalling it (pending a decision on whether to roll the two up). To roll back, uninstall it and reinstall the original.

I'm reasonably confident that it won't break anyone's system but it hasn't seen much in the way of Windows. Please post any issues here.

Update: 2.0-2 fixes:
Update: 2.0-1 fixes:
  • service-control interface always showed mdnsd not running;
  • upgrade installation left both mdnsd versions running;
  • static address mappings appended to hosts file lost.


  • zeroconf_2.0-2_mipsel.opk
    21 KB · Views: 1
Last edited:


Ad detector
What problem is this package supposed to address?
Who might need it and why?
To say it is upgrade to mdnsd doesn't help me since I can't find any reference to that on forums, package catalog or wiki.


Well-Known Member
What problem is this package supposed to address?
As linked above. Basically, never type an IP address for a CF Humax again. You need this, I think.

Some contexts (Foxlink, eg) may require an IP address until fixed.

mDNS is a LAN-local protocol for name assignment and address resolution. In Mac and Windows you get this with Apple Bonjour. In Linux, Avahi is the typical package used. You would then be able to type, say for the box named myhumax, myhumax.local into your browser address bar or bookmark to access myhumax's WebIf.

The implementation used on the HD/R comes from a package called tinysvcmdns.

The existing package worked for the purpose named in the linked thread title, but had two problems:
  • the machine would advertise its DNS name (eg, myhumax.local), but other HD/R CF machines were unable to resolve that name (because name resolution in the Humax Linux is fixed to use /etc/hosts only, and incoming name -> address mappings were not processed and certainly not populated into the hosts file);
  • the name -> address mapping didn't update with setup_hosts, typically leading to the IP address being advertised as if it used a wireless LAN connection with DHCP; a work-around was to monitor /etc/hosts and restart the mDNS daemon on changes.
Last edited: