Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

An mDNS query that works

Here is an example of the response that is returned from runway.local:

enter image description here

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):

enter image description here

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.

share|improve this question
    
I should add that if I log in to the DreamPlug aka plug over SSH and execute the command ping 224.0.0.251 which is the mDNS multicast address, I get the result connect: Network is unreachable -- not sure if this is supposed to be happening but may be useful for anyone who can help. –  jon Nov 10 '11 at 17:58
    
Update: 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: 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. –  jon Nov 14 '11 at 12:43
    
It looks like you've got an answer there. Can you upgrade your Avahi on the DreamPlug? –  Bill Weiss Nov 15 '11 at 4:32
3  
What about using a real DNS server apart from Avahi? Something like bind / named. Have you tried doing tis? –  jap1968 Dec 14 '11 at 21:40
2  
Fantastic question with lots of detail! If you figure it out, write your own answer and mark it with a checkmark - this helps others and might even give you rep points. –  Mei Feb 15 '12 at 23:48

1 Answer 1

up vote 1 down vote accepted

I don't frequent SF so frequently, but I can see that this question has attracted a fair bit of attention, so let me just summarise my findings here, and hopefully provide something of a solution to those experiencing the same issue:-

It seems that this is a bug with the version of Avahi that ships with Ubuntu Jaunty (http://avahi.org/ticket/284) to do with supplying the UDP payload size, likely as a result in a more reccent change to the mDNS spec (though I haven't read it myself). As I explained in the comments to the original question, I did try to upgrade my version of Avahi, but my Linux skills are not what they should be and I didn't manage to get it to work. (Either way, running a 3 year old unsupported OS is really not recommended anyway...)

In the end, I took the plunge, wiped the SD card of the DreamPlug and installed Debian Squeeze on it, which worked fine (albeit only with iOS 5.0+). A discussion of how to change the DreamPlug OS is out of scope of this question, but what it all boils down to at the end of the day is an out of date version of Avahi. Use a newer version and you should be fine!

Good luck!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.