nsswitch.conf says: hosts: files dns mdns4 This means that for a .local lookup it does a DNS lookup *first*. Which will fail. Urgh. The recommended solution is to use nss_mdns >= 0.8 (released 2006) and: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 (see http://0pointer.de/lennart/projects/nss-mdns/)
Prior art: Fedora does http://pkgs.fedoraproject.org/gitweb/?p=nss-mdns.git;a=blob;f=nss-mdns.spec Debian's postinst is in http://packages.debian.org/sid/libnss-mdns
libnss_mdns has been updated to 0.10. Bug still to be fixed for R1.3. Regards, Cristian
Hi Ross, Can you please provide a way to test case for this bug? Thanks, Cristian
$ ping somehost.local Where somehost is the hostname of another machine on your network. avahi-browse -a will list all the local ones. On my Debian desktop with working mDNS the resolution happens in a fraction of a second: $ time ping -c 1 base.local PING base.local (192.168.1.3) 56(84) bytes of data. 64 bytes from base.local (192.168.1.3): icmp_req=1 ttl=64 time=2.37 ms --- base.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.374/2.374/2.374/0.000 ms real 0m0.108s user 0m0.000s sys 0m0.000s (that's the first run, subsequent runs are ~0.01s real time because the lookup has been cached) On my Yocto machine, the first resolution takes several seconds whilst the DNS is queried for a name that isn't in it.
QA will give an ETA for testing this issue during WW27. Regards, Cristian
Tested with 1.3 on a FRI2 Core-image-sato-sdk Behavior reporduces with the mentioned changes in /etc/nsswitch.conf. Subsequent calls return the same result as the first call.
Investigation ongoing. Proposed solution is not sufficient.
Fix applied in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=36d4dcfe6a3ad937caaae299923ae79b918520e1
1) The patch is applied in master but not in danny. Tested on jasperforest and sugarbay. " nsswitch.conf says: hosts: files dns mdns4 " 2) RP: I tried your suggested test plan on a master build with the patch applied and these are my results: " root@qemuppc:~# time ping -c 1 NODE1.local PING NODE1.local (192.168.7.1): 56 data bytes 64 bytes from 192.168.7.1: seq=0 ttl=64 time=4.335 ms --- NODE1.local ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 4.335/4.335/4.335 ms real 0m0.081s user 0m0.036s sys 0m0.036s root@qemuppc:~# time ping -c 1 NODE1.local PING NODE1.local (192.168.7.1): 56 data bytes 64 bytes from 192.168.7.1: seq=0 ttl=64 time=0.568 ms --- NODE1.local ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.568/0.568/0.568 ms real 0m0.045s user 0m0.004s sys 0m0.032s root@qemuppc:~# time ping -c 1 NODE1.local PING NODE1.local (192.168.7.1): 56 data bytes 64 bytes from 192.168.7.1: seq=0 ttl=64 time=0.521 ms --- NODE1.local ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.521/0.521/0.521 ms real 0m0.036s user 0m0.004s sys 0m0.020s " It would seem a dns lookup is done judging by the ping timers. 3) Ignoring the ping timers, the ping itself is successful on both danny (with no patch) and master (with patch). The hostname resolution is done using mdns as dns does not know of NODE1.local .
The problem has been fixed in commit 36d4dcfe6a3ad937caaae299923ae79b918520e1. Cheers, Constantin
Verified in master: 36d4dcfe6a3ad937caaae299923ae79b918520e1 . Will open a new one for danny.