I have the following very peculiar issue with using Avahi on the DreamPlug (which is a plug computer running Ubuntu Jaunty).
After spending days on this, I think I've managed to narrow down the issue.
The DreamPlug acts as the WiFi access point, and has the hostname plug and IP address 192.168.1.1 (which is set in both /etc/hosts and /etc/hostname) and runs lighttpd.
Now my Mac works straight away with accessing http://plug.local in Chrome, however if I try and load http://plug.local on the iPad, it doesn't work. That is, it doesn't work until I load the page on the desktop.
For some reason, the iPads are never able to resolve the hostname, until the hostname is first resolved on the Mac... which is weird because there is no connection between the iPads and the Mac other than the fact that they are connected to the same access point (the DreamPlug).
So just to clarify again: Safari on the iPad will hang (until it reports that browsing failed) when accessing http://plug.local unless I access http://plug.local on the Mac, run ping plug.local, do ssh root@plug.local or basically do anything else that resolves the hostname, at which point the iPad instantly resolves the hostname and it starts working properly.
If my understanding is correct, when the iPads connect they broadcast a resolution request for plug.local. For whatever reason, this request is ignored by the DreamPlug (or it never gets received). However, the Mac does manage to broadcast its request. It broadcasts a resolution request and the DreamPlug brodcasts back the result plug.local -> 192.168.1.1. The iPads then receive this result (which was really destined for the Mac) and are then able to resolve successfully.
I'd be happy to supply my avahi-daemon.conf or other config files on request.
Update: I've now managed to use Wireshark and found that the iPads do indeed broadcast a request to the network.
I've captured both a packet that DID result in a response from Avahi, as well as one that did NOT.
They both appear completely identical, the only difference is that the one that failed specified an additional RR of type OPT... I have no idea what an OPT record is. Could it be that Avahi doesn't like DNS queries with OPT RRs attached for some reason?
Here are two screenshots taken from Wireshark. The first one shows a "good" mDNS request which is sent from the desktop computer (in this case, the device is called runway.local). This query works fine and the server (at 192.168.1.1) responds straight away:
Here is an example of the response that is returned from runway.local:
Meanwhile, here is a second DNS query which has been sent from the iPad for the same hostname, runway.local. In this case, the request seems to be simply ignored (in any event, no response is ever received for this DNS query):
Trying to track down what it is in the iPad request that causes the issue, it appears that the two packets are almost identical, the only difference between mDNS queries sent from the desktop (running OS X) and the iPad, is that the iPad appends an OPT resource record to the bottom of the DNS request.
The question is: what is the significance of the resource record -- and is it this -- or is it something else -- that is responsible for this DNS request being ignored by Avahi.
UPDATE This could be the breakthrough I've been looking for:
I've been running avahi-daemon with --debug flag and I've noticed a lot of "Invalid query packet." messages. This led me to this page: http://avahi.org/ticket/284 which seems that this is a known issue (albeit one that's supposed to be resolved).
Specifically:
A tcpdump makes me believe that this is due to Mac OS 10.6 using RFC2671 to add information in the additional data section of DNS queries. Specifically, it is supplying the 'UDP payload size' (in my case, 1440) as hint for the max size of response packets. [...] Avahi considers queries with non-empty additional data sections invalid, where it checks that AVAHI_DNS_FIELD_ARCOUNT != 0 just before generating the Invalid query packet message.
