Utilizzo di Avahi su DreamPlug Ubuntu con iPad

Ho il seguente problema molto particolare con l'uso di Avahi su DreamPlug (che è un computer plug-in con Ubuntu Jaunty).

Dopo aver trascorso giorni su questo, penso di essere riuscito a restringere il problema.

DreamPlug funge da punto di accesso WiFi e ha il nome host pluge l'indirizzo IP 192.168.1.1(che è impostato in entrambi /etc/hostse /etc/hostname) ed esegue lighttpd.

Ora il mio Mac funziona immediatamente con l'accesso http://plug.locala Chrome, tuttavia se provo a caricare http://plug.locall'iPad, non funziona. Cioè, non funziona fino a quando non carico la pagina sul desktop.

Per qualche motivo, gli iPad non sono mai in grado di risolvere il nome host, fino a quando il nome host non viene risolto per la prima volta sul Mac ... il che è strano perché non esiste una connessione tra iPad e Mac oltre al fatto che sono collegati al stesso punto di accesso (il DreamPlug).

Quindi, solo per chiarire di nuovo: Safari su iPad si bloccherà (fino a quando non segnala che la navigazione non è riuscita) quando si accede a http://plug.localmeno che non acceda http://plug.localsu Mac, eseguo ping plug.local, faccia ssh root@plug.localo sostanzialmente faccia qualsiasi altra cosa che risolva il nome host, a quel punto l'iPad risolve immediatamente il nome host e inizia a funzionare correttamente.

Se la mia comprensione è corretta, quando gli iPad si connettono trasmettono una richiesta di risoluzione per plug.local. Per qualsiasi motivo, questa richiesta viene ignorata da DreamPlug (o non viene mai ricevuta). Tuttavia, il Mac non riesce a trasmettere la sua richiesta. Trasmette una richiesta di risoluzione e DreamPlug trasmette il risultato plug.local-> 192.168.1.1. Gli iPad ricevono quindi questo risultato (che era davvero destinato al Mac) e sono quindi in grado di risolversi con successo.

Sarei felice di fornire il mio avahi-daemon.confo altri file di configurazione su richiesta.

Aggiornamento: ora sono riuscito a utilizzare Wireshark e ho scoperto che gli iPad trasmettono effettivamente una richiesta alla rete.

Ho catturato sia un pacchetto che ha provocato una risposta da Avahi, sia uno che NON lo ha fatto.

Entrambi sembrano completamente identici, l'unica differenza è che quello che ha fallito ha specificato un RR aggiuntivo di tipo OPT... Non ho idea di cosa sia un OPTrecord. Potrebbe essere che ad Avahi non piacciano le query DNS con OPTRR collegati per qualche motivo?

Ecco due schermate tratte da Wireshark. Il primo mostra una "buona" richiesta mDNS che viene inviata dal computer desktop (in questo caso, il dispositivo viene chiamato runway.local). Questa query funziona correttamente e il server (at 192.168.1.1) risponde immediatamente:

Ecco un esempio della risposta che viene restituita da runway.local:

Nel frattempo, ecco un seconda query DNS che è stato inviato da iPad per lo stesso nome host, runway.local. In questo caso, la richiesta sembra essere semplicemente ignorata (in ogni caso, non viene mai ricevuta alcuna risposta per questa query DNS):

Cercando di rintracciare ciò che è nella richiesta iPad che causa il problema, sembra che i due pacchetti siano quasi identici, l'unica differenza tra le query mDNS inviate dal desktop (con OS X) e l'iPad è che l'iPad aggiunge un OPTrecord di risorse nella parte inferiore della richiesta DNS.

La domanda è: qual è il significato del record di risorse - ed è questo - o è qualcos'altro - che è responsabile per questa richiesta DNS che viene ignorata da Avahi.

AGGIORNAMENTO Questa potrebbe essere la svolta che stavo cercando:

Ho eseguito avahi-daemon con --debug flag e ho notato un sacco di "pacchetto di query non valido". messaggi. Questo mi ha portato a questa pagina: http://avahi.org/ticket/284 che sembra che si tratti di un problema noto (anche se dovrebbe essere risolto).

In particolare:

Un tcpdump mi fa credere che ciò sia dovuto a Mac OS 10.6 che utilizza RFC2671 per aggiungere informazioni nella sezione dati aggiuntivi delle query DNS. In particolare, sta fornendo la "dimensione del payload UDP" (nel mio caso 1440) come suggerimento per la dimensione massima dei pacchetti di risposta. [...] Avahi considera non valide le query con sezioni di dati aggiuntivi non vuoti, in cui verifica che AVAHI_DNS_FIELD_ARCOUNT! = 0 appena prima di generare il messaggio Pacchetto di query non valido.

Non frequento così frequentemente la SF, ma posso vedere che questa domanda ha attirato un bel po 'di attenzione, quindi lasciami riassumere i miei risultati qui, e spero di fornire qualcosa di una soluzione a coloro che hanno lo stesso problema: -

Sembra che questo sia un bug con la versione di Avahi fornita con Ubuntu Jaunty ( http://avahi.org/ticket/284 ) per fornire la dimensione del payload UDP, probabilmente come risultato di una modifica più reccent alla Specifiche mDNS (anche se non l'ho letto da solo). Come ho spiegato nei commenti alla domanda originale, ho provato ad aggiornare la mia versione di Avahi, ma le mie competenze su Linux non sono come dovrebbero essere e non sono riuscito a farlo funzionare. (Ad ogni modo, l'esecuzione di un sistema operativo non supportato di 3 anni non è comunque consigliata ...)

Alla fine, ho fatto il grande passo, ho cancellato la scheda SD del DreamPlug e ho installato Debian Squeeze su di esso, che ha funzionato bene (anche se solo con iOS 5.0+). Una discussione su come cambiare il sistema operativo DreamPlug non rientra nell'ambito di questa domanda, ma a cosa si riduce alla fine della giornata è una versione obsoleta di Avahi. Usa una versione più recente e dovresti andare bene!

In bocca al lupo!