Korzystanie z Avahi na DreamPlug Ubuntu z iPadami

Mam następujący bardzo szczególny problem z używaniem Avahi na DreamPlug (który jest komputerem z wtyczką z Ubuntu Jaunty).

Po spędzeniu kilku dni na tym myślę , że udało mi się zawęzić problem.

DreamPlug działa jako punkt dostępu WiFi, ma nazwę hosta plugi adres IP 192.168.1.1(który jest ustawiony zarówno na /etc/hostsi /etc/hostname), jak i działa lighttpd.

Teraz mój komputer Mac działa od razu z dostępem http://plug.localdo Chrome, ale jeśli spróbuję załadować http://plug.localna iPadzie, to nie działa. Oznacza to, że nie działa, dopóki nie załaduję strony na pulpit.

Z jakiegoś powodu iPady nigdy nie są w stanie rozpoznać nazwy hosta, dopóki nazwa hosta nie zostanie najpierw rozpoznana na komputerze Mac ... co jest dziwne, ponieważ nie ma połączenia między iPadem a komputerem Mac poza faktem, że są one podłączone do komputera ten sam punkt dostępu (DreamPlug).

Aby wyjaśnić jeszcze raz: Safari na iPadzie zawiesi się (dopóki nie zgłosi, że przeglądanie nie powiodło się) podczas uzyskiwania dostępu, http://plug.localchyba że mam dostęp http://plug.localdo komputera Mac, nie uruchamiam ping plug.local, nie robię ssh [email protected]lub w zasadzie nic innego, co rozwiązuje nazwę hosta. nazwa hosta i zaczyna działać poprawnie.

Jeśli dobrze rozumiem, po podłączeniu iPadów wysyłają żądanie rozwiązania plug.local. Z jakiegokolwiek powodu żądanie to jest ignorowane przez DreamPlug (lub nigdy nie zostaje odebrane). Jednak Mac nie uda się nadawać swój wniosek. Emituje żądanie rozwiązania, a brodcast DreamPlug przekazuje wynik plug.local-> 192.168.1.1. Następnie iPady otrzymują ten wynik (który był naprawdę przeznaczony dla komputerów Mac) i są w stanie pomyślnie rozwiązać.

Z przyjemnością dostarczę moje avahi-daemon.conflub inne pliki konfiguracyjne na żądanie.

Aktualizacja: Udało mi się teraz korzystać z Wireshark i odkryłem, że iPady rzeczywiście wysyłają żądanie do sieci.

Przechwyciłem zarówno pakiet, który DID dał odpowiedź Avahi, jak i taki, który NIE.

Obydwie wydają się całkowicie identyczne, jedyna różnica polega na tym, że ten, który zawiódł, określił dodatkowe RR typu OPT... Nie mam pojęcia, co to OPTjest rekord. Czy to możliwe, że Avahi z OPTjakiegoś powodu nie lubi zapytań DNS z RR dołączonymi?

Oto dwa zrzuty ekranu zrobione z Wireshark. Pierwszy pokazuje „dobre” żądanie mDNS, które jest wysyłane z komputera stacjonarnego (w tym przypadku nazywane jest urządzenie runway.local). To zapytanie działa dobrze, a serwer (at 192.168.1.1) odpowiada natychmiast:

Oto przykład odpowiedzi zwróconej z runway.local:

Tymczasem, oto drugie zapytanie DNS, który został wysłany z iPada do tego samego hosta, runway.local. W takim przypadku żądanie wydaje się po prostu zignorowane (w żadnym wypadku nie otrzymano odpowiedzi na to zapytanie DNS):

Próbując wyśledzić, co jest przyczyną żądania iPada, wydaje się, że dwa pakiety są prawie identyczne, jedyną różnicą między zapytaniami mDNS wysyłanymi z pulpitu (z systemem OS X) i iPada jest to, że iPad dołącza OPTrekord zasobu do dołu żądanie DNS.

Pytanie brzmi: jakie jest znaczenie rekordu zasobu - i czy to - czy też jest to coś innego - odpowiedzialnego za ignorowanie tego żądania DNS przez Avahi.

AKTUALIZACJA To może być przełom, którego szukałem:

Uruchomiłem demona avahi z flagą --debug i zauważyłem wiele „nieprawidłowych pakietów zapytań”. wiadomości. Doprowadziło mnie to do tej strony: http://avahi.org/ticket/284, która wydaje się, że jest to znany problem (choć taki, który powinien zostać rozwiązany).

Konkretnie:

Program tcpdump sprawia, że ​​uważam, że jest to spowodowane tym, że system Mac OS 10.6 używa RFC2671 do dodawania informacji w sekcji danych dodatkowych zapytań DNS. W szczególności dostarcza „rozmiar ładunku UDP” (w moim przypadku 1440) jako wskazówkę dotyczącą maksymalnego rozmiaru pakietów odpowiedzi. [...] Avahi uznaje zapytania z niepustymi dodatkowymi sekcjami danych za nieprawidłowe, sprawdzając, czy AVAHI_DNS_FIELD_ARCOUNT! = 0 tuż przed wygenerowaniem komunikatu nieprawidłowego pakietu zapytań.

Nieczęsto korzystam z SF, ale widzę, że to pytanie przyciągnęło sporo uwagi, więc pozwólcie, że streszczę tutaj moje ustalenia i mam nadzieję, że przedstawię rozwiązanie dla osób, które mają ten sam problem:

Wygląda na to, że jest to błąd związany z wersją Avahi dostarczaną z Ubuntu Jaunty ( http://avahi.org/ticket/284 ) związaną z dostarczaniem wielkości ładunku UDP, prawdopodobnie w wyniku bardziej powtarzającej się zmiany specyfikacja mDNS (chociaż sam jej nie przeczytałem). Jak wyjaśniłem w komentarzach do pierwotnego pytania, próbowałem zaktualizować moją wersję Avahi, ale moje umiejętności w zakresie Linuksa nie są takie, jakie powinny być i nie udało mi się go uruchomić. (Tak czy inaczej, uruchomienie 3-letniego nieobsługiwanego systemu operacyjnego i tak naprawdę nie jest zalecane ...)

W końcu podjąłem decyzję, wytarłem kartę SD DreamPlug i zainstalowałem na niej Debian Squeeze, który działał dobrze (choć tylko z iOS 5.0+). Dyskusja o tym, jak zmienić DreamPlug OS, nie wchodzi w zakres tego pytania, ale to, co sprowadza się do końca dnia, to przestarzała wersja Avahi. Użyj nowszej wersji i wszystko będzie dobrze!

Powodzenia!