Saya memiliki masalah yang sangat aneh berikut ini dengan menggunakan Avahi di DreamPlug (yang merupakan komputer steker yang menjalankan Ubuntu Jaunty).
Setelah menghabiskan waktu berhari-hari untuk hal ini, saya pikir saya berhasil mempersempit masalah ini.
DreamPlug bertindak sebagai titik akses WiFi, dan memiliki nama host plugdan alamat IP 192.168.1.1(yang diatur dalam keduanya /etc/hostsdan /etc/hostname) dan menjalankan lighttpd.
Sekarang Mac saya langsung berfungsi dengan mengakses http://plug.localdi Chrome, namun jika saya mencoba memuat http://plug.localdi iPad, Mac tidak berfungsi. Artinya, itu tidak berfungsi sampai saya memuat halaman di desktop.
Untuk beberapa alasan, iPad tidak pernah dapat menyelesaikan nama host, hingga nama host tersebut pertama kali diselesaikan pada Mac ... yang aneh karena tidak ada koneksi antara iPad dan Mac selain fakta bahwa mereka terhubung ke jalur akses yang sama (DreamPlug).
Jadi hanya untuk mengklarifikasi lagi: Safari di iPad akan hang (sampai melaporkan bahwa penjelajahan gagal) ketika mengakses http://plug.localkecuali saya mengakses http://plug.localdi Mac, jalankan ping plug.local, lakukan ssh root@plug.localatau pada dasarnya melakukan apa pun yang menyelesaikan nama host, di mana saat itu iPad secara instan menyelesaikan nama host dan mulai berfungsi dengan baik.
Jika pemahaman saya benar, ketika iPads terhubung mereka menyiarkan permintaan resolusi plug.local. Untuk alasan apa pun, permintaan ini diabaikan oleh DreamPlug (atau tidak pernah diterima). Namun, Mac tidak berhasil menyiarkan permintaannya. Ini menyiarkan permintaan resolusi dan brodcast DreamPlug kembali hasilnya plug.local-> 192.168.1.1. IPad kemudian menerima hasil ini (yang benar-benar diperuntukkan bagi Mac) dan kemudian berhasil diselesaikan.
Saya akan dengan senang hati menyediakan avahi-daemon.conffile konfigurasi saya atau lainnya berdasarkan permintaan.
Pembaruan: Saya sekarang berhasil menggunakan Wireshark dan menemukan bahwa iPad memang menyiarkan permintaan ke jaringan.
Saya telah menangkap kedua paket yang TIDAK menghasilkan respons dari Avahi, serta yang TIDAK.
Mereka berdua tampak sama persis, satu-satunya perbedaan adalah bahwa yang gagal menentukan RR tipe tambahan OPT... Saya tidak tahu apa itu OPTcatatan. Mungkinkah Avahi tidak menyukai permintaan DNS dengan OPTRR yang dilampirkan karena alasan tertentu?
Berikut adalah dua tangkapan layar yang diambil dari Wireshark. Yang pertama menunjukkan permintaan mDNS "baik" yang dikirim dari komputer desktop (dalam hal ini, perangkat disebut runway.local). Kueri ini berfungsi dengan baik dan server (at 192.168.1.1) langsung merespons:

Berikut adalah contoh respons yang dikembalikan dari runway.local:

Sementara itu, di sini adalah permintaan DNS kedua yang telah dikirim dari iPad untuk nama host yang sama runway.local,. Dalam hal ini, permintaan tampaknya diabaikan begitu saja (dalam keadaan apa pun, tidak pernah ada respons yang diterima untuk permintaan DNS ini):

Mencoba melacak apa yang ada dalam permintaan iPad yang menyebabkan masalah, tampak bahwa kedua paket hampir identik, satu-satunya perbedaan antara permintaan mDNS yang dikirim dari desktop (menjalankan OS X) dan iPad, adalah bahwa iPad menambahkan sebuah OPTcatatan sumber daya ke bagian bawah permintaan DNS.
Pertanyaannya adalah: apa arti penting dari catatan sumber daya - dan apakah ini - atau ini sesuatu yang lain - yang bertanggung jawab atas permintaan DNS yang diabaikan oleh Avahi.
PEMBARUAN Ini bisa menjadi terobosan yang saya cari:
Saya telah menjalankan avahi-daemon dengan flag --debug dan saya perhatikan banyak "Paket query tidak valid." pesan. Ini menuntun saya ke halaman ini: http://avahi.org/ticket/284 yang tampaknya merupakan masalah yang diketahui (meskipun yang seharusnya diselesaikan).
Secara khusus:
Tcpdump membuat saya percaya bahwa ini karena Mac OS 10.6 menggunakan RFC2671 untuk menambahkan informasi di bagian data tambahan dari permintaan DNS. Secara khusus, ini memasok 'ukuran muatan UDP' (dalam kasus saya, 1440) sebagai petunjuk untuk ukuran maksimal paket respons. [...] Avahi menganggap kueri dengan bagian data tambahan yang tidak kosong tidak valid, di mana ia mengecek bahwa AVAHI_DNS_FIELD_ARCOUNT! = 0 sebelum membuat pesan paket kueri yang tidak valid.
plugmelalui SSH dan menjalankan perintahping 224.0.0.251yang merupakan alamat multicast mDNS, saya mendapatkan hasilnyaconnect: Network is unreachable- tidak yakin apakah ini seharusnya terjadi tetapi mungkin bermanfaat bagi siapa saja yang dapat membantu.