This post (with its thread) is to document what we know about DNS resolution in the HD/HDR-Fox T2 systems.
At the root is the uClibc resolver. In theory this behaves like the glibc resolver in desktop/server Linux, as described in the resolv.conf manual page, but, libc being uC, the theory is approximate.
The uClibc version in use doesn't correspond to any version in the uClibc source code repository. Broadcom devs abstracted a now defunct branch that implemented NPTL multi-threading corresponding to the 0.9.29 trunk version, but the resulting resolver code in uClibc-nptl-0.9.29-20070423.tar[.gz] from the Humax Open Source download page (also find it at the Broadcom GitHub site) is significantly different from both the 0.9.29 trunk version and also from the first trunk release with NPTL (0.9.32, 2012-06). The busy commit log is a bit concerning. Only the main options described for resolv.conf are supported.
Using the libc resolver, a host DNS lookup queries the first IP address listed as
However, in normal operation the uClibc resolver isn't the only component that's used in resolving DNS addresses. The Humax devs installed the dnsmasq, v2.56, utility as a caching DNS proxy (the build configuration also supports TFTP). They forgot to tell the lawyers, though, as dnsmasq isn't offered from the Humax Open Source page with other GPL sources: surely Humax didn't relicense it? Legality aside, dnsmasq is expected to be running before the set-top program is launched, being launched by the
With dnsmasq listening on 127.0.0.1 and that address listed as the first nameserver entry in
But
The Humax set-top program contains a network configuration module, whose UI is accessed by Menu>Settings>System>Internet Setting, which probably assumes that there is only one actual LAN interface, either eth0 or wlan0. If the interface is configured for DHCP, the DNS setting (list of name server(s)) can be provided by the DHCP server; otherwise it has to be entered in the "Configure LAN" page. The set-top program writes these entries into
The first line causes a lookup for an unqualified hostname XXX to be interpreted as looking up XXX.bad, and therefore, as expected by the Humax devs in 2010, returning non-existent domain. Now that almost any old junk can be a TLD, "search invalid" should be used instead.
The second line forces resolution by a local DNS server (such as dnsmasq), if available.
The next lines, which may be repeated, list the name servers configured manually or by DHCP.
Finally, if DHCP is in use, the udhcpc action script
The DNS Address value shown on the "Configure LAN" page is (apparently) the address from the first nameserver entry in
dnsmasq in the configured version polls
The above all applies to both stock and custom FW, but working it out or changing its behaviour requires the custom FW.
The dnsmasq binary, startup script and configuration file are stored in the read-only root filesystem. Various options exist for modifying its behaviour:
This causes dnsmasq to log all queries to stderr, so you can see what DNS names are being used by the system, eg by JS loaded into the set-top program's browser module by a TV Portal app.
At the root is the uClibc resolver. In theory this behaves like the glibc resolver in desktop/server Linux, as described in the resolv.conf manual page, but, libc being uC, the theory is approximate.
The uClibc version in use doesn't correspond to any version in the uClibc source code repository. Broadcom devs abstracted a now defunct branch that implemented NPTL multi-threading corresponding to the 0.9.29 trunk version, but the resulting resolver code in uClibc-nptl-0.9.29-20070423.tar[.gz] from the Humax Open Source download page (also find it at the Broadcom GitHub site) is significantly different from both the 0.9.29 trunk version and also from the first trunk release with NPTL (0.9.32, 2012-06). The busy commit log is a bit concerning. Only the main options described for resolv.conf are supported.
Using the libc resolver, a host DNS lookup queries the first IP address listed as
nameserver <IP> in /etc/resolv.conf, trying each nameserver entry in turn until one doesn't time out. This is also true for the uClibc resolver: however, the "rotate" resolv.conf option, which would start with each listed name server in turn, isn't understood (only "nameserver", "domain", and "search").However, in normal operation the uClibc resolver isn't the only component that's used in resolving DNS addresses. The Humax devs installed the dnsmasq, v2.56, utility as a caching DNS proxy (the build configuration also supports TFTP). They forgot to tell the lawyers, though, as dnsmasq isn't offered from the Humax Open Source page with other GPL sources: surely Humax didn't relicense it? Legality aside, dnsmasq is expected to be running before the set-top program is launched, being launched by the
/etc/init.d/S41dnsmasq startup script.With dnsmasq listening on 127.0.0.1 and that address listed as the first nameserver entry in
/etc/resolv.conf, a host DNS lookup goes to dnsmasq, and only to any other listed servers if that times out. dnsmasq in turn will return a reply if it has a valid cached or configured answer to the query, or forward the query to each of the next listed servers until one doesn't time out. There's some dnsmasq configuration in the read-only /etc/dnsmasq.conf:
Code:
# try each name server in turn, instead of using dnsmasq's health metric
strict-order
# receive DNS lookups
listen-address=127.0.0.1
# DNS and TFTP only
no-dhcp-interface=eth0
no-dhcp-interface=wlan0
# don't read /etc/hosts
no-hosts/etc/resolv.conf should also be read-only, so how do the name servers get added? In fact this read-only flash file is a symbolic link to /var/lib/humaxtv/resolv.conf, which is writable.The Humax set-top program contains a network configuration module, whose UI is accessed by Menu>Settings>System>Internet Setting, which probably assumes that there is only one actual LAN interface, either eth0 or wlan0. If the interface is configured for DHCP, the DNS setting (list of name server(s)) can be provided by the DHCP server; otherwise it has to be entered in the "Configure LAN" page. The set-top program writes these entries into
/etc/resolv.conf, replacing any previous contents (which dnsmasq will have been using so far):
Code:
search bad
nameserver 127.0.0.1
nameserver <DNS setting>
...
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 8.8.8.8
nameserver 8.8.4.4The second line forces resolution by a local DNS server (such as dnsmasq), if available.
The next lines, which may be repeated, list the name servers configured manually or by DHCP.
Finally, if DHCP is in use, the udhcpc action script
/usr/share/udhcpc/default.script adds the local IP address for dnsmasq and two well-known server addresses for OpenDNS and two more for Google's DNS. This seems like overkill, but could have saved Humax some support calls due to badly configured home routers setting invalid DNS server(s) by DHCP, or due to bad manual DNS addresses (Problem Existing Between Couch And Screen). Although the uClibc resolver, like traditional libc resolvers, only looks at the first 3 name servers, dnsmasq doesn't have such a limit.The DNS Address value shown on the "Configure LAN" page is (apparently) the address from the first nameserver entry in
/etc/resolv.conf that is not 127.0.0.1.dnsmasq in the configured version polls
/etc/resolv.conf to get the latest name server list; recent versions know how to use libinotify. The program ignores any instance of its "listen-address" in the returned list and uses the list according to the specified "strict-order" option (rendering the long list of DNS servers irrelevant). In this way the same resolv.conf can be used regardless of whether dnsmasq is running.The above all applies to both stock and custom FW, but working it out or changing its behaviour requires the custom FW.
The dnsmasq binary, startup script and configuration file are stored in the read-only root filesystem. Various options exist for modifying its behaviour:
- to change the configuration, you can create a new configuration file, bind-mount it over
/etc/dnsmasq.conf, and restart dnsmasq; generally any option that could be specified on the dnsmasq command line can be put in the configuration file using the long option name without its -- prefix, as shown in an example below; - to run dnsmasq in a more sophisticated way, create a new startup script in
/mod/etc/init.dto implement the desired behaviour: as part of its 'start' action, the script should stop the built-in dnsmasq before launching dnsmasq again, and vice versa; - you can build a new version of dnsmasq: eg, I tried 2.82-2-ga2a7e04 from the GitHub site, which could be built on-box with some header file munging to deal with missing IPv6 definitions; then run it using method 2 above.
-8 - -q command-line options, or equivalently the configuration options:
Code:
log-facility=-
log-queriesl
Last edited:
