在iPad上的DreamPlug Ubuntu上使用Avahi
在DreamPlug（这是运行Ubuntu Jaunty的即插式计算机）上使用Avahi时，我遇到以下非常特殊的问题。 花了几天时间之后，我认为我已经设法缩小了问题的范围。 DreamPlug充当WiFi接入点，具有主机名plug和IP地址192.168.1.1（在/etc/hosts和中设置/etc/hostname），并运行lighttpd。 现在，我的Mac可以直接http://plug.local在Chrome中访问，但是如果我尝试http://plug.local在iPad上加载，它将无法正常工作。就是说，直到我将页面加载到桌面上，它才起作用。 由于某种原因，iPad永远无法解析主机名，直到在Mac上首先解析主机名为止。相同的访问点（DreamPlug）。 因此，请再次澄清一下：http://plug.local除非我http://plug.local在Mac上访问，运行ping plug.local，执行ssh root@plug.local或基本上执行任何其他可解析主机名的操作，否则iPad上的Safari浏览器将在访问时挂起（直到报告浏览失败），此时iPad会立即解析该主机名。主机名，它开始正常工作。 如果我的理解是正确的，则在连接iPad时，它们会广播的解析请求plug.local。无论出于何种原因，DreamPlug都会忽略此请求（或者永远不会收到它）。但是，Mac 确实可以广播其请求。它广播一个解析请求，然后DreamPlug brodcast返回结果plug.local-> 192.168.1.1。然后，iPad收到此结果（该结果确实是Mac的），然后可以成功解析。 我很乐意根据要求提供我的avahi-daemon.conf配置文件或其他配置文件。 更新：我现在设法使用Wireshark，发现iPad确实确实向网络广播了一个请求。 我捕获了DID导致Avahi做出响应的数据包，以及没有得到的数据包。 它们看起来完全相同，唯一的区别是，失败的记录指定了其他类型的RR OPT...我不知道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请求底部的资源记录。 问题是：资源记录的意义是什么-是-还是其他原因-导致该DNS请求被Avahi忽略。 更新这可能是我一直在寻找的突破： 我一直在使用--debug标志运行avahi-daemon，并且注意到很多“无效的查询数据包”。消息。这导致我转到此页面：http : //avahi.org/ticket/284，这似乎是一个已知问题（尽管应该解决）。 特别： 一个tcpdump使我相信这是由于Mac OS 10.6使用RFC2671在DNS查询的其他数据部分中添加了信息。具体来说，它提供“ UDP有效负载大小”（在我的情况下为1440）作为响应包最大大小的提示。[...] Avahi认为带有非空附加数据节的查询无效，在此之前，Avahi会在生成无效查询数据包消息之前检查AVAHI_DNS_FIELD_ARCOUNT！= 0。