花了好几天后,我想我已经设法缩小了这个问题.

DreamPlug充当WiFi接入点,具有主机名插头和IP地址192.168.1.1(在/ etc / hosts和/ etc / hostname中设置)并运行lighttpd.

现在我的Mac可以直接在Chrome中访问http：//plug.local,但是如果我尝试在iPad上加载http：//plug.local,它就无法正常工作.也就是说,在我在桌面上加载页面之前它不起作用.

出于某种原因,iPad永远不能解析主机名,直到主机名首先在Mac上解析…这很奇怪,因为iPad和Mac之间没有连接,除了它们连接到相同的访问点(DreamPlug).

所以只是再次澄清：当访问http：//plug.local时,iPad上的Safari将挂起(直到它报告浏览失败),除非我在Mac上访问http：//plug.local,运行ping plug.local,do ssh root@plug.local或基本上做任何解析主机名的事情,此时iPad立即解析主机名并开始正常工作.

如果我的理解是正确的,当iPad连接时,他们会广播对plug.local的解析请求.无论出于何种原因,DreamPlug都会忽略此请求(或者永远不会收到此请求).但是,Mac确实设法广播其请求.它广播一个解析请求,DreamPlug brodcasts返回结果plug.local – > 192.168.1.1.然后iPad会收到这个结果(这真的是为了Mac),然后才能成功解决.

我很乐意根据您的要求提供我的avahi-daemon.conf或其他配置文件.

更新：我现在设法使用Wireshark,发现iPad确实向网络广播了一个请求.

我已经捕获了一个DID导致Avahi响应的数据包,以及没有得到的数据包.

它们看起来完全相同,唯一的区别是失败的那个指定了OPT类型的额外RR ……我不知道OPT记录是什么.难道Avahi不喜欢因某些原因附加了OPT RR的DNS查询吗？

以下是两个截取Wireshark的截图.第一个显示从桌面计算机发送的“好”mDNS请求(在这种情况下,该设备称为runway.local).此查询工作正常,服务器(在192.168.1.1)立即响应：

以下是从runway.local返回的响应示例：

同时,这是第二个DNS查询,它已从iPad发送到相同的主机名runway.local.在这种情况下,请求似乎被忽略(在任何情况下,此DNS查询都没有收到任何响应)：

试图追踪导致问题的iPad请求中的内容,看起来两个数据包几乎完全相同,从桌面(运行OS X)和iPad发送的mDNS查询之间的唯一区别在于iPad附加了一个OPT资源记录到DNS请求的底部.

问题是：资源记录的重要性是什么 – 它是否是 – 或者是其他东西 – 负责Avahi忽略此DNS请求.

更新这可能是我一直在寻找的突破：

我一直用–debug标志运行avahi-daemon,我注意到了很多“无效的查询包”.消息.这导致我进入这个页面：http://avahi.org/ticket/284这似乎是一个已知的问题(尽管应该解决的问题).

特别：

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.