У меня есть следующая очень странная проблема с использованием Avahi на DreamPlug (это подключаемый компьютер с Ubuntu Jaunty).
Потратив на это несколько дней, думаю, мне удалось сузить проблему.
DreamPlug действует как точка доступа Wi-Fi, имеет имя хоста plug
и IP-адрес 192.168.1.1
(который установлен в обоих /etc/hosts
и /etc/hostname
) и запускает lighttpd.
Теперь мой Mac сразу работает с доступом http://plug.local
в Chrome, однако, если я попытаюсь загрузить http://plug.local
iPad, он не будет работать. То есть, это не работает, пока я не загружу страницу на рабочий стол.
По какой-то причине iPad никогда не сможет разрешить имя хоста, пока имя хоста не будет впервые разрешено на Mac ... что странно, поскольку между iPad и Mac нет соединения, за исключением того, что они подключены к та же точка доступа (DreamPlug).
Просто чтобы уточнить еще раз: Safari на iPad будет зависать (пока не сообщит, что просмотр не удался) при доступе, http://plug.local
если я не получаю доступ http://plug.local
на Mac, не запускаю ping plug.local
, не делаю ssh root@plug.local
и не делаю вообще ничего, что разрешает имя хоста, после чего iPad мгновенно разрешает имя хоста, и он начинает работать правильно.
Если я правильно понимаю, когда iPad подключается, они передают запрос разрешения plug.local
. По какой-то причине этот запрос игнорируется DreamPlug (или он никогда не будет получен). Тем не менее, Mac делает управление вещать свой запрос. Он передает запрос разрешения, и DreamPlug передает результат обратно plug.local
-> 192.168.1.1
. Затем iPad получает этот результат (который действительно предназначен для Mac) и затем может успешно разрешить.
Я был бы рад предоставить мои avahi-daemon.conf
или другие файлы конфигурации по запросу.
Обновление: теперь я смог использовать Wireshark и обнаружил, что iPad действительно передает запрос в сеть.
Я захватил как пакет, который ДЕЙСТВИТЕЛЬНО привел к ответу от Avahi, так и пакет, который НЕ сделал.
Они оба выглядят абсолютно идентичными, единственное отличие состоит в том, что тот, который потерпел неудачу, указал дополнительный RR типа OPT
... Я понятия не имею, что такое OPT
запись. Может быть, Avahi OPT
по какой-то причине не нравится DNS-запросы с RR?
Вот два скриншота, сделанные из Wireshark. Первый показывает «хороший» mDNS-запрос, который отправляется с настольного компьютера (в этом случае вызывается устройство runway.local
). Этот запрос работает нормально, и сервер (в 192.168.1.1
) отвечает сразу:
Вот пример ответа, который возвращается из runway.local
:
Между тем, вот второй DNS-запрос, который был отправлен с iPad для того же имени хоста runway.local
. В этом случае запрос, кажется, просто игнорируется (в любом случае, ответ на этот запрос DNS не получен):
Пытаясь отследить, что именно в запросе iPad вызывает проблему, создается впечатление, что два пакета практически идентичны, единственное различие между запросами mDNS, отправляемыми с рабочего стола (под управлением OS X) и iPad, заключается в том, что iPad добавляет OPT
запись ресурса в нижней части запроса DNS.
Вопрос заключается в следующем: каково значение записи ресурса - и является ли это - или это что-то еще - что ответственно за игнорирование этого запроса DNS Avahi.
ОБНОВЛЕНИЕ Это может быть прорыв, который я искал:
Я запускаю avahi-daemon с флагом --debug и часто замечаю «Неверный пакет запроса». Сообщения. Это привело меня к этой странице: http://avahi.org/ticket/284, которая, кажется, известна (хотя и должна быть решена).
В частности:
Tcpdump заставляет меня поверить, что это связано с Mac OS 10.6, использующей RFC2671 для добавления информации в раздел дополнительных данных DNS-запросов. В частности, он предоставляет «размер полезной нагрузки UDP» (в моем случае 1440) в качестве подсказки для максимального размера ответных пакетов. [...] Avahi считает запросы с непустыми дополнительными разделами данных недействительными, где он проверяет, что AVAHI_DNS_FIELD_ARCOUNT! = 0 непосредственно перед генерацией сообщения пакета недопустимых запросов.
plug
через SSH и выполню команду,ping 224.0.0.251
являющуюся адресом многоадресной рассылки mDNS, я получу результатconnect: Network is unreachable
- не уверен, что это должно произойти, но может быть полезным для любого, кто может помочь.