У мене є наступна дуже своєрідна проблема використання 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 дійсно передає запит у мережу.
Я захопив як пакет, що DID спричинив відповідь від Avahi, так і той, який НЕ.
Вони обидва видаються абсолютно однаковими, різниця лише в тому, що той, який не вдався, вказав додатковий RR типу OPT... Я поняття не маю, що таке OPTзапис. Можливо, Avahi OPTчомусь не любить запити DNS із доданими RR?
Ось два скріншоти, зняті з Wireshark. Перший показує "хороший" mDNS-запит, який надсилається з настільного комп'ютера (у цьому випадку пристрій викликається runway.local). Цей запит працює нормально, і сервер (at 192.168.1.1) відповідає відразу:
Ось приклад відповіді, яка повертається з runway.local:
Тим часом, тут є другий DNS - запит , який був відправлений з Статкевич ж ім'я хоста, runway.local. У цьому випадку запит, як видається, просто ігнорується (у будь-якому випадку, відповідь на цей запит DNS ніколи не надходить):
Намагаючись відстежити, що саме в запиті iPad викликає проблему, виявляється, що два пакети майже однакові. Єдина відмінність між запитами mDNS, що надсилаються з робочого столу (на базі ОС X) та iPad, полягає в тому, що iPad додає запис OPTресурсу в нижній частині запиту DNS.
Питання полягає в тому, яке значення запису ресурсів - і чи це це - чи це щось інше - це відповідальність за ігнорування цього запиту DNS від Avahi.
ОНОВЛЕННЯ Це міг бути проривом, який я шукав:
Я запускав avahi-демон з прапором --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- не впевнений, чи це має відбуватися, але може бути корисним для всіх, хто може допомогти.