Utilisation d'Avahi sur DreamPlug Ubuntu avec des iPads

J'ai le problème très particulier suivant avec l'utilisation d'Avahi sur le DreamPlug (qui est un ordinateur plug exécutant Ubuntu Jaunty).

Après avoir passé des jours là-dessus, je pense que j'ai réussi à réduire le problème.

Le DreamPlug fait office de point d'accès WiFi, possède le nom d'hôte pluget l'adresse IP 192.168.1.1(qui sont définis dans les deux /etc/hostset /etc/hostname) et exécute lighttpd.

Maintenant, mon Mac fonctionne immédiatement avec l'accès http://plug.localà Chrome, mais si j'essaie de charger http://plug.localsur l'iPad, cela ne fonctionne pas. Autrement dit, cela ne fonctionne que lorsque je charge la page sur le bureau.

Pour une raison quelconque, les iPads ne sont jamais en mesure de résoudre le nom d'hôte, jusqu'à ce que le nom d'hôte soit d'abord résolu sur le Mac ... ce qui est bizarre car il n'y a pas de connexion entre les iPads et le Mac autre que le fait qu'ils sont connectés au même point d'accès (le DreamPlug).

Donc, pour clarifier encore une fois: Safari sur l'iPad se bloquera (jusqu'à ce qu'il signale que la navigation a échoué) lors de l'accès à http://plug.localmoins que j'accède http://plug.localsur le Mac, que j'exécute ping plug.local, fasse ssh root@plug.localou fasse essentiellement autre chose qui résout le nom d'hôte, auquel cas l'iPad résout instantanément le nom d'hôte et il commence à fonctionner correctement.

Si ma compréhension est correcte, lorsque les iPad se connectent, ils diffusent une demande de résolution pour plug.local. Pour une raison quelconque, cette demande est ignorée par le DreamPlug (ou elle n'est jamais reçue). Cependant, le Mac ne parviennent à diffuser sa demande. Il diffuse une demande de résolution et la broderie DreamPlug renvoie le résultat plug.local-> 192.168.1.1. Les iPad reçoivent alors ce résultat (qui était vraiment destiné au Mac) et sont ensuite en mesure de résoudre avec succès.

Je serais heureux de fournir mon avahi-daemon.confou d'autres fichiers de configuration sur demande.

Mise à jour: J'ai maintenant réussi à utiliser Wireshark et j'ai constaté que les iPad diffusaient effectivement une demande au réseau.

J'ai capturé à la fois un paquet dont DID a résulté en une réponse d'Avahi, ainsi que celui qui ne l'a PAS fait.

Ils ont tous deux l'air complètement identiques, la seule différence est que celui qui a échoué a spécifié un RR supplémentaire de type OPT... Je n'ai aucune idée de ce qu'est un OPTenregistrement. Se pourrait-il qu'Avahi n'aime pas les requêtes DNS avec des OPTRR attachés pour une raison quelconque?

Voici deux captures d'écran tirées de Wireshark. Le premier montre une "bonne" demande mDNS qui est envoyée depuis l'ordinateur de bureau (dans ce cas, le périphérique est appelé runway.local). Cette requête fonctionne correctement et le serveur (at 192.168.1.1) répond immédiatement:

Voici un exemple de la réponse renvoyée par runway.local:

Pendant ce temps, voici une deuxième requête DNS qui a été envoyé à partir de l'iPad pour le même nom d' hôte, runway.local. Dans ce cas, la demande semble être simplement ignorée (en tout état de cause, aucune réponse n'est jamais reçue pour cette requête DNS):

En essayant de retrouver ce qui se trouve dans la demande iPad qui cause le problème, il semble que les deux paquets soient presque identiques, la seule différence entre les requêtes mDNS envoyées depuis le bureau (exécutant OS X) et l'iPad, c'est que l'iPad ajoute un OPTenregistrement de ressource au bas de la demande DNS.

La question est: quelle est la signification de l'enregistrement de ressource - et est-ce - ou est-ce autre chose - qui est responsable de l'ignorance de cette demande DNS par Avahi.

MISE À JOUR Cela pourrait être la percée que je cherchais:

J'ai exécuté avahi-daemon avec l'indicateur --debug et j'ai remarqué beaucoup de "paquet de requête non valide". messages. Cela m'a conduit à cette page: http://avahi.org/ticket/284 qui semble être un problème connu (bien qu'il soit censé être résolu).

Plus précisément:

Un tcpdump me fait croire que cela est dû à Mac OS 10.6 utilisant RFC2671 pour ajouter des informations dans la section de données supplémentaires des requêtes DNS. Plus précisément, il fournit la «taille de charge utile UDP» (dans mon cas, 1440) comme indice de la taille maximale des paquets de réponse. [...] Avahi considère les requêtes avec des sections de données supplémentaires non vides non valides, où il vérifie que AVAHI_DNS_FIELD_ARCOUNT! = 0 juste avant de générer le message de paquet de requête non valide.

Je ne fréquente pas le SF si souvent, mais je peux voir que cette question a attiré un peu d'attention, alors permettez-moi de résumer mes conclusions ici, et j'espère apporter une solution à ceux qui rencontrent le même problème: -

Il semble que ce soit un bogue avec la version d'Avahi fournie avec Ubuntu Jaunty ( http://avahi.org/ticket/284 ) pour fournir la taille de la charge utile UDP, probablement en conséquence d'un changement plus récent de Spécification mDNS (même si je ne l'ai pas lu moi-même). Comme je l'ai expliqué dans les commentaires à la question d'origine, j'ai essayé de mettre à niveau ma version d'Avahi, mais mes compétences Linux ne sont pas ce qu'elles devraient être et je n'ai pas réussi à le faire fonctionner. (Quoi qu'il en soit, l'exécution d'un système d'exploitation non pris en charge de 3 ans n'est vraiment pas recommandée de toute façon ...)

En fin de compte, j'ai franchi le pas, essuyé la carte SD du DreamPlug et installé Debian Squeeze dessus, ce qui fonctionnait bien (mais uniquement avec iOS 5.0+). Une discussion sur la façon de changer le système d'exploitation DreamPlug est hors de portée de cette question, mais ce qui se résume à la fin de la journée est une version obsolète d'Avahi. Utilisez une version plus récente et ça devrait aller!

Bonne chance!