Usando Avahi en DreamPlug Ubuntu con iPads

Tengo el siguiente problema muy peculiar con el uso de Avahi en DreamPlug (que es una computadora enchufable que ejecuta Ubuntu Jaunty).

Después de pasar días en esto, creo que he logrado reducir el problema.

El DreamPlug actúa como punto de acceso Wi-Fi, y tiene el nombre de host plugy la dirección IP 192.168.1.1(que se encuentra en tanto /etc/hostsy /etc/hostname) y se ejecuta LightTPD.

Ahora mi Mac funciona directamente con el acceso http://plug.localen Chrome, sin embargo, si intento cargar http://plug.localen el iPad, no funciona. Es decir, no funciona hasta que cargue la página en el escritorio.

Por alguna razón, los iPads nunca pueden resolver el nombre de host, hasta que el nombre de host se resuelve por primera vez en la Mac ... lo cual es extraño porque no hay conexión entre los iPads y la Mac aparte del hecho de que están conectados a la mismo punto de acceso (DreamPlug).

Entonces, para aclarar nuevamente: Safari en el iPad se bloqueará (hasta que informe que la navegación falló) al acceder a http://plug.localmenos que acceda http://plug.localen la Mac, ejecute ping plug.local, haga ssh [email protected]o básicamente haga cualquier otra cosa que resuelva el nombre de host, momento en el cual el iPad resuelve instantáneamente nombre de host y comienza a funcionar correctamente.

Si mi comprensión es correcta, cuando los iPads se conectan, transmiten una solicitud de resolución plug.local. Por alguna razón, DreamPlug ignora esta solicitud (o nunca la recibe). Sin embargo, el Mac hace logran transmitir su petición. Emite una solicitud de resolución y DreamPlug retransmite el resultado plug.local-> 192.168.1.1. Los iPads luego reciben este resultado (que realmente estaba destinado a Mac) y luego pueden resolverse con éxito.

Estaré encantado de proporcionar mi avahi-daemon.confu otros archivos de configuración a petición.

Actualización: ahora he logrado usar Wireshark y descubrí que los iPads realmente transmiten una solicitud a la red.

Capturé un paquete que resultó en una respuesta de Avahi, así como uno que NO.

Ambos parecen completamente idénticos, la única diferencia es que el que falló especificó un RR adicional de tipo OPT... No tengo idea de qué es un OPTregistro. ¿Podría ser que a Avahi no le gustan las consultas DNS con OPTRR adjuntos por alguna razón?

Aquí hay dos capturas de pantalla tomadas de Wireshark. La primera muestra una solicitud mDNS "buena" que se envía desde la computadora de escritorio (en este caso, se llama al dispositivo runway.local). Esta consulta funciona bien y el servidor (at 192.168.1.1) responde de inmediato:

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

Mientras tanto, aquí hay una segunda consulta DNS que ha sido enviado desde el iPad para el mismo nombre de host, runway.local. En este caso, la solicitud parece simplemente ignorarse (en cualquier caso, nunca se recibe respuesta para esta consulta DNS):

Intentando rastrear qué hay en la solicitud del iPad que causa el problema, parece que los dos paquetes son casi idénticos, la única diferencia entre las consultas mDNS enviadas desde el escritorio (ejecutando OS X) y el iPad, es que el iPad agrega un OPTregistro de recursos al final de la solicitud de DNS.

La pregunta es: ¿cuál es la importancia del registro de recursos? ¿Es esto, o es otra cosa, lo que es responsable de que Avahi ignore esta solicitud de DNS?

ACTUALIZACIÓN Este podría ser el avance que he estado buscando:

He estado ejecutando avahi-daemon con el indicador --debug y he notado muchos "paquetes de consulta no válidos". mensajes Esto me llevó a esta página: http://avahi.org/ticket/284, que parece ser un problema conocido (aunque se supone que debe resolverse).

Específicamente:

Un tcpdump me hace creer que esto se debe a que Mac OS 10.6 usa RFC2671 para agregar información en la sección de datos adicionales de las consultas DNS. Específicamente, está proporcionando el 'tamaño de carga útil UDP' (en mi caso, 1440) como una pista para el tamaño máximo de los paquetes de respuesta. [...] Avahi considera que las consultas con secciones de datos adicionales no vacías no son válidas, donde comprueba que AVAHI_DNS_FIELD_ARCOUNT! = 0 justo antes de generar el mensaje de paquete de consulta no válido.

No frecuenta la SF con tanta frecuencia, pero puedo ver que esta pregunta ha atraído bastante atención, así que permítanme resumir mis hallazgos aquí y, con suerte, ofrecer una solución para aquellos que experimentan 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 tiene que ver con el suministro del tamaño de la carga útil UDP, probablemente como resultado de un cambio más reciente en el Especificación de mDNS (aunque no lo he leído yo mismo). Como expliqué en los comentarios a la pregunta original, intenté actualizar mi versión de Avahi, pero mis habilidades con Linux no son lo que deberían ser y no pude hacer que funcionara. (De cualquier manera, ejecutar un SO no compatible de 3 años realmente no se recomienda de todos modos ...)

Al final, me lancé, limpié la tarjeta SD del DreamPlug e instalé Debian Squeeze, que funcionó bien (aunque solo con iOS 5.0+). Una discusión sobre cómo cambiar el sistema operativo DreamPlug está fuera del alcance de esta pregunta, pero a fin de cuentas todo se reduce a una versión desactualizada de Avahi. ¡Usa una versión más nueva y deberías estar bien!

¡Buena suerte!