Tengo el siguiente muy peculiar problema con el uso de Avahi en el DreamPlug (que es un plug equipo que ejecuta Ubuntu Jaunty).
Después de pasar días en esto, yo creo que me las he arreglado para reducir el problema.
El DreamPlug actúa como punto de acceso WiFi, y tiene el nombre de host plug
y la dirección IP 192.168.1.1
(que se establece en tanto /etc/hosts
y /etc/hostname
) y se ejecuta lighttpd.
Ahora mi Mac funciona directamente con el acceso a la http://plug.local
de Cromo, sin embargo si intento cargar http://plug.local
en el iPad, no funciona. Es decir, no funciona hasta que se carga la página en el escritorio.
Por alguna razón, los iPads, nunca son capaces de resolver el nombre de host, hasta que el nombre de host se resuelve en primer lugar en el Mac... lo cual es raro porque no hay ninguna conexión entre el ipad y el Mac, aparte del hecho de que están conectados al mismo punto de acceso (el DreamPlug).
Así que para aclarar de nuevo: Safari en el iPad se bloquea (hasta que se informa de que la navegación error) cuando se accede http://plug.local
menos que puedo acceder a http://plug.local
en el Mac, ejecute ping plug.local
, do ssh root@plug.local
o, básicamente, cualquier cosa que se resuelve el nombre de host, al punto que el iPad al instante resuelve el nombre de la máquina y empieza a funcionar correctamente.
Si mi interpretación es correcta, cuando el ipad se conecte que la emisión de la resolución de la solicitud de plug.local
. Por la razón que sea, esta solicitud es ignorado por el DreamPlug (o que nunca se recibió). Sin embargo, el Mac no administrar a la difusión de su solicitud. Difunde una solicitud de resolución y el DreamPlug brodcasts vuelta el resultado plug.local
-> 192.168.1.1
. El ipad, a continuación, recibir este resultado (que en realidad era destinado para el Mac) y luego son capaces de resolver con éxito.
Yo estaría encantado de proporcionar a mis avahi-daemon.conf
u otros archivos de configuración a petición.
Actualización: ahora he podido utilizar Wireshark y se encontró que el ipad de hecho, la emisión de una solicitud a la red.
He capturado tanto en un paquete que se tradujo en una respuesta de Avahi, así como uno que NO lo hizo.
Ambos aparecen completamente idénticos, la única diferencia es que el que no se ha podido especificado un adicional de RR de tipo OPT
... no tengo idea de lo que es un OPT
registro. Podría ser que Avahi no le gusta a las consultas DNS con OPT
Rr conectados por alguna razón?
Aquí son dos capturas de pantalla tomadas de Wireshark. La primera muestra de "buena" mDNS solicitud que se envía desde el ordenador de escritorio (en este caso, el dispositivo se llama runway.local
). Esta consulta funciona bien y el servidor (en 192.168.1.1
) responde de inmediato:
Aquí es un ejemplo de la respuesta que se devuelve desde runway.local
:
Mientras tanto, aquí está una segunda consulta DNS que ha sido enviado desde el iPad, para el mismo nombre de host, runway.local
. En este caso, la petición parece ser simplemente ignorado (en cualquier caso, ninguna respuesta es siempre recibido para esta consulta DNS):
Tratando de rastrear a lo que es en el iPad solicitud que causa el problema, parece que los dos paquetes son casi idénticos, la única diferencia entre mDNS las consultas enviadas desde el escritorio (el sistema operativo OS X) y el iPad, es que el iPad se anexa un OPT
registro de recurso a la parte inferior de la petición DNS.
La pregunta es: ¿cuál es la importancia del registro de recursos -- y es -- o es algo más -- que es el responsable de esta petición DNS siendo ignorados por Avahi.
La ACTUALIZACIÓN de Este podría ser el gran avance que he estado buscando:
He estado corriendo avahi-daemon --con indicador de depuración y me he dado cuenta de un montón de "no Válido paquete de consulta." los mensajes. Esto me llevó a esta página: http://avahi.org/ticket/284 que parece que este es un problema conocido (aunque sea uno que se supone que va a ser resuelto).
Específicamente:
Un tcpdump me hace creer que esto es debido a que Mac OS 10.6 uso de RFC2671 para agregar información en la sección de datos adicionales de DNS las consultas. Específicamente, es el suministro de la 'UDP carga de tamaño' (en mi caso, 1440) como sugerencia para el tamaño máximo de los paquetes de respuesta. [...] Avahi considera que las consultas con los no-vacío adicionales secciones de datos no válidos, donde se comprueba que AVAHI_DNS_FIELD_ARCOUNT != 0 justo antes de la generación de la consulta no es válida mensaje de paquete.