(Bu Ubuntu Jaunty çalıştıran bir fiş bilgisayar) DreamPlug Avahi kullanarak aşağıdaki çok tuhaf bir sorun var.
Bu günleri geçirdikten sonra ben düşünüyorum Sorunu daraltmak için idare ettik.
DreamPlug WiFi erişim noktası olarak görev yapar ve ana bilgisayar adını alır plugve IP adresini 192.168.1.1(her ikisi ayarlanır /etc/hostsve /etc/hostname) ve çalışır lighttpd'nin.
Şimdi Mac'im http://plug.localChrome'a erişmekle hemen çalışıyor , ancak http://plug.localiPad'i yüklemeye ve yüklemeye çalışırsam çalışmıyor. Yani, sayfayı masaüstüne yükleyene kadar çalışmıyor .
Herhangi bir nedenle, iPad'ler ana makine adı Mac'te ilk olarak çözülene kadar ana bilgisayar adını asla çözemez ... bu tuhaftır, çünkü iPad'lerle Mac arasında, bağlantıya bağlı olmaları dışında bir bağlantı yoktur. aynı erişim noktası (DreamPlug).
(Başarısız gezinirken raporlarını kadar) erişirken iPad'de Safari askıda kalacaktır: Yani sadece tekrar netleştirmek için http://plug.localerişmeye sürece http://plug.localMac, kaçak ping plug.local, yapmak ssh root@plug.localveya temelde yapmak şey giderir iPad bu noktada ana makine adı, anında giderdiğini başka hostname ve düzgün çalışmaya başlar.
Anlayışım doğruysa, iPad'ler bağlandığında, bir çözünürlük isteği yayınlarlar plug.local. Hangi nedenle olursa olsun, bu istek DreamPlug tarafından yok sayılır (veya asla alınmaz). Ancak, Mac yapar talebini yayınlamak için yönetmek. Bir çözümleme isteği yayınlar ve DreamPlug sonucu yayınlar plug.local-> 192.168.1.1. İPad'ler daha sonra bu sonucu (Mac için gerçekten hedeflenmiş) alır ve daha sonra başarılı bir şekilde çözebilir.
avahi-daemon.confTalep üzerine benim veya diğer yapılandırma dosyalarımı sunmaktan memnuniyet duyarım .
Güncelleme: Artık Wireshark'ı kullanmayı başardım ve iPad'lerin gerçekten ağa bir istek yayınladığını gördüm.
Hem Avahi'den bir yanıtla sonuçlanan bir paket hem de YAPMADI bir paket yakaladım.
Her ikisi de tamamen aynı görünüyor, tek fark başarısız olan ek bir RR türü belirtmek olduğunu OPT... Bir OPTkayıt ne olduğu hakkında hiçbir fikrim yok . Avahi, OPTbir nedenden ötürü RR'ler eklenmiş DNS sorgularını sevmiyor olabilir mi?
İşte Wireshark'tan iki ekran görüntüsü. Birincisi, masaüstü bilgisayardan gönderilen "iyi" bir mDNS isteği gösterir (bu durumda cihaz çağrılır runway.local). Bu sorgu 192.168.1.1düzgün çalışıyor ve sunucu (at ) hemen yanıt veriyor:
Aşağıda verilen yanıtın bir örneği verilmiştir runway.local:
Bu arada, aynı ana bilgisayar adı için iPad'den gönderilen ikinci bir DNS sorgusu runway.local. Bu durumda, istek basit bir şekilde yok sayılır (her durumda, bu DNS sorgusu için hiçbir yanıt alınmaz):
Soruna neden olan iPad isteğinde ne olduğunu bulmaya çalışırken, iki paketin neredeyse aynı olduğu, masaüstünden (OS X çalıştıran) ve iPad'den gönderilen mDNS sorguları arasındaki tek fark, iPad'in OPTDNS isteğinin altına bir kaynak kaydı.
Soru şu: Kaynak kaydının önemi nedir - ve bu mu - yoksa başka bir şey mi - bu DNS isteğinin Avahi tarafından göz ardı edilmesinden sorumludur.
GÜNCELLEME Bu aradığım atılım olabilir:
Avahi-daemon'u --debug bayrağıyla çalıştırıyorum ve bir çok "Geçersiz sorgu paketi" gördüm. mesajlar. Bu beni şu sayfaya götürdü: http://avahi.org/ticket/284 , bunun bilinen bir sorun olduğu anlaşılıyor (çözülmesi gereken bir sorun olsa da).
özellikle:
Bir tcpdump, bunun DNS sorgularının ek veri bölümüne bilgi eklemek için RFC2671 kullanan Mac OS 10.6'dan kaynaklandığına inanıyor. Özellikle, yanıt paketlerinin maksimum boyutu için ipucu olarak 'UDP yük boyutu' (benim durumumda, 1440) sağlıyor. [...] Avahi, boş olmayan ek veri bölümlerine sahip sorguları geçersiz kabul eder; burada Geçersiz sorgu paketi mesajı oluşturmadan hemen önce AVAHI_DNS_FIELD_ARCOUNT! = 0 olup olmadığını kontrol eder.
plugSSH üzerinden DreamPlug aka oturumping 224.0.0.251ve mDNS çok noktaya yayın adresi olan komutu yürütmek , sonuç almakconnect: Network is unreachable- bunun olması gerekiyordu emin değilim ama yardımcı olabilecek herkes için yararlı olabilir eklemek gerekir.