Использование Avahi на DreamPlug Ubuntu с iPad

У меня есть следующая очень специфическая проблема с использованием 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 или в основном делать что-нибудь else, который разрешает имя хоста, после чего iPad мгновенно разрешает имя хоста, и он начинает работать правильно.

Если я правильно понимаю, когда iPad подключается, они транслируют запрос разрешения для plug.local. По какой-то причине DreamPlug игнорирует этот запрос (или никогда не получает). Однако Mac делает удалось передать свой запрос. Он передает запрос разрешения, а DreamPlug возвращает результат plug.local -> 192.168.1.1. Затем iPad получает этот результат (который действительно был предназначен для Mac), а затем могут успешно разрешиться.

Я был бы рад предоставить свой avahi-daemon.conf или другие файлы конфигурации по запросу.

Обновить: Теперь мне удалось использовать Wireshark и обнаружил, что iPad действительно транслирует запрос в сеть.

Я захватил как пакет, который ДЕЙСТВИТЕЛЬНО привел к ответу от Avahi, так и тот, который НЕ дал.

Они оба выглядят полностью идентичными, с той лишь разницей, что в том, что не удалось, была указана дополнительная запись типа OPT... Понятия не имею, что за OPT запись есть. Может быть, Авахи не любит DNS-запросы с OPT 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 непосредственно перед генерацией сообщения о недопустимом пакете запроса.