Eu tenho o seguinte problema muito peculiar com o uso do Avahi no DreamPlug (que é um plug computer rodando o Ubuntu Jaunty).
Depois de passar dias nisso, acho que consegui restringir o assunto.
O DreamPlug atua como o ponto de acesso Wi-Fi e tem o nome do host plug e o endereço IP 192.168.1.1 (que é definido em /etc/hosts e /etc/hostname ) e executa o lighttpd.
Agora, meu Mac funciona imediatamente acessando http://plug.local no Chrome, mas se eu tentar e carregar http://plug.local no iPad, não funcionará. Ou seja, não funciona até que eu carregue a página na área de trabalho.
Por algum motivo, os iPads nunca são capazes de resolver o nome do host, até que o nome do host seja resolvido primeiro no Mac ... o que é estranho porque não há conexão entre os iPads e o Mac além do fato de que eles são conectado ao mesmo ponto de acesso (o DreamPlug).
Então, só para esclarecer novamente: o Safari no iPad irá travar (até que relate que a navegação falhou) ao acessar http://plug.local a menos que eu acesse http://plug.local no Mac, execute ping plug.local , do ssh [email protected] ou basicamente faz qualquer outra outra que resolva o nome do host, ponto em que o iPad instantaneamente resolve o nome do host e ele começa a funcionar corretamente.
Se meu entendimento estiver correto, quando os iPads se conectarem, eles transmitirão uma solicitação de resolução para plug.local . Por qualquer motivo, este pedido é ignorado pelo DreamPlug (ou nunca é recebido). No entanto, o Mac faz gerenciar para transmitir sua solicitação. Ele transmite uma solicitação de resolução e o DreamPlug envia o resultado plug.local - > %código%. Os iPads recebem então o resultado (que foi realmente destinado ao Mac) e são capazes de resolver com sucesso.
Eu ficaria feliz em fornecer meu 192.168.1.1 ou outros arquivos de configuração a pedido.
Atualização: Agora consegui usar o Wireshark e descobri que os iPads de fato transmitem uma solicitação para a rede.
Capturei um pacote que DID resultou em uma resposta do Avahi, bem como um que NÃO fez.
Ambos parecem completamente idênticos, a única diferença é que o que falhou especificou um RR adicional do tipo avahi-daemon.conf ... Não tenho ideia do que é um OPT record. Será que o Avahi não gosta de consultas DNS com OPT RRs anexadas por algum motivo?
Aqui estão dois screenshots tirados do Wireshark. O primeiro mostra uma "boa" solicitação mDNS que é enviada do computador desktop (nesse caso, o dispositivo é chamado OPT ). Esta consulta funciona bem e o servidor (em runway.local ) responde imediatamente:
Aquiestáumexemplodarespostaretornadade192.168.1.1:
Enquanto isso, aqui está uma segunda consulta DNS que foi enviada do iPad para o mesmo nome de host, runway.local . Nesse caso, a solicitação parece ser simplesmente ignorada (em qualquer caso, nenhuma resposta é recebida para essa consulta DNS):
TentandorastrearoqueénasolicitaçãodoiPadquecausaoproblema,parecequeosdoispacotessãoquaseidênticos,aúnicadiferençaentreasconsultasmDNSenviadasdaáreadetrabalho(executandooOSX)eoiPadéqueoiPadanexaumregistroderecursorunway.localàparteinferiordasolicitaçãodeDNS.
Aquestãoé:qualéosignificadodoregistroderecurso-eéisso-ouéoutracoisa-queéresponsávelporessasolicitaçãodeDNSserignoradapelaAvahi.
UPDATEEssepodeserograndeavançoqueeutenhoprocurado:
Eutenhoexecutadooavahi-daemoncomosinalizador--debugenoteimuitos"pacotes de consulta inválidos". mensagens. Isso me levou a esta página: link que parece ser um problema conhecido (apesar de ser um problema resolvido).
Especificamente:
A tcpdump makes me believe that this is due to Mac OS 10.6 using
RFC2671 to add information in the additional data section of DNS
queries. Specifically, it is supplying the 'UDP payload size' (in my
case, 1440) as hint for the max size of response packets. [...] Avahi
considers queries with non-empty additional data sections invalid,
where it checks that AVAHI_DNS_FIELD_ARCOUNT != 0 just before
generating the Invalid query packet message.