17 votos

El uso de Avahi en DreamPlug Ubuntu con iPads

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:

An mDNS query that works

Aquí es un ejemplo de la respuesta que se devuelve desde runway.local:

enter image description here

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):

enter image description here

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.

1voto

jon Puntos 193

Yo no frecuente SF con tanta frecuencia, pero puedo ver que esta cuestión ha atraído un poco justo de la atención, así que permítanme resumir mis conclusiones aquí, y esperamos que proporcionan algo de una solución para aquellos que están experimentando el mismo problema:-

Parece que este es un error con la versión de Avahi que se incluye con Ubuntu Jaunty (http://avahi.org/ticket/284) que ver con el suministro de la UDP carga de tamaño, probablemente como resultado de una más reccent cambio a la mDNS spec (aunque yo no lo he leído yo). Como he explicado en el comentario a la pregunta original, me hizo intentar actualizar mi versión de Avahi, pero mi Linux no son lo que deberían ser y no he podido hacerlo funcionar. (De cualquier manera, la ejecución de un niño de 3 años no compatible sistema operativo es muy recomendable de todos modos...)

En el final, me tomó de la caída, se limpió la tarjeta SD de el DreamPlug e instalado Debian Squeeze, que funcionaba bien (aunque sólo con iOS 5.0+). Una discusión de cómo cambiar el DreamPlug OS queda fuera del alcance de esta pregunta, pero lo que todo se reduce al final del día es una versión no actualizada de Avahi. Usar una versión más reciente y que debe estar bien!

Buena suerte!

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: