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


17

У меня есть следующая очень странная проблема с использованием 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.localiPad, он не будет работать. То есть, это не работает, пока я не загружу страницу на рабочий стол.

По какой-то причине 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) отвечает сразу:

MDNS-запрос, который работает

Вот пример ответа, который возвращается из 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 непосредственно перед генерацией сообщения пакета недопустимых запросов.


Я должен добавить, что если я войду в DreamPlug или plugчерез SSH и выполню команду, ping 224.0.0.251являющуюся адресом многоадресной рассылки mDNS, я получу результат connect: Network is unreachable- не уверен, что это должно произойти, но может быть полезным для любого, кто может помочь.
джон

Обновление: я запускаю avahi-daemon с флагом --debug, и я заметил много «Неверный пакет запроса». Сообщения. Это привело меня к этой странице: avahi.org/ticket/284, которая, кажется, известна (хотя и должна быть решена). В частности: tcpdump заставляет меня поверить, что это связано с Mac OS 10.6, использующей RFC2671 для добавления информации в раздел дополнительных данных DNS-запросов. В частности, он предоставляет «размер полезной нагрузки UDP» (в моем случае 1440) в качестве подсказки для максимального размера ответных пакетов.
джон

Похоже, у вас есть ответ там. Можете ли вы обновить Avahi на DreamPlug?
Билл Вайс

3
Как насчет использования реального DNS-сервера, кроме Avahi? Что-то вроде bind / named. Вы пытались сделать это?
jap1968

2
Фантастический вопрос с большим количеством деталей! Если вы поймете это, напишите свой собственный ответ и отметьте его галочкой - это поможет другим и даже может дать вам очки репутации.
Мэй

Ответы:


1

Я не часто бываю в SF, но я вижу, что этот вопрос привлек к себе немало внимания, поэтому позвольте мне кратко изложить свои выводы и, надеюсь, найти решение для тех, кто испытывает ту же проблему: -

Похоже, что это ошибка в версии Avahi, поставляемой с Ubuntu Jaunty ( http://avahi.org/ticket/284 ), связанной с предоставлением размера полезной нагрузки UDP, что, вероятно, приведет к более быстрому изменению Спецификация mDNS (хотя я сам не читал). Как я объяснил в комментариях к первоначальному вопросу, я попытался обновить свою версию Avahi, но мои навыки Linux не такие, какими они должны быть, и мне не удалось заставить ее работать. (В любом случае, запуск 3-летней неподдерживаемой ОС действительно не рекомендуется ...)

В конце я сделал решающий шаг, вытер SD-карту DreamPlug и установил на нее Debian Squeeze, которая работала нормально (хотя и только с iOS 5.0+). Обсуждение того, как изменить DreamPlug OS, выходит за рамки этого вопроса, но то, к чему все сводится в конце дня, является устаревшей версией Avahi. Используйте более новую версию, и у вас все будет хорошо!

Удачи!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.