Avahi - Chromebook: não foi possível resolver o nome do host

Question

Eu tenho um raspberry pi (raspbian jessie) com ssh & serviços de vnc registrados em avahi. Consigo ver os dois serviços no meu cliente (chromebook)

chronos@localhost ~ $ avahi-browse -arl
+  mlan0 IPv4 raspberrypi SSH                               _ssh._tcp            local
+  mlan0 IPv4 raspberrypi VNC                               _rfb._tcp            local
+  mlan0 IPv4 raspberrypi [30:b5:c2:1e:2f:df]               _workstation._tcp    local
=  mlan0 IPv4 raspberrypi SSH                               _ssh._tcp            local
   hostname = [raspberrypi.local]
   address = [192.168.1.200]
   port = [22]
   txt = []
=  mlan0 IPv4 raspberrypi [30:b5:c2:1e:2f:df]               _workstation._tcp    local
   hostname = [raspberrypi.local]
   address = [192.168.1.200]
   port = [9]
   txt = []
=  mlan0 IPv4 raspberrypi VNC                               _rfb._tcp            local
   hostname = [raspberrypi.local]
   address = [192.168.1.200]
   port = [5900]
   txt = []

E parece que posso resolver o nome e o endereço:

chronos@localhost ~ $ avahi-resolve --address 192.168.1.200
192.168.1.200   raspberrypi.local
chronos@localhost ~ $ avahi-resolve --name raspberrypi.local
raspberrypi.local       192.168.1.200

Mas sempre que tento fazer ping ou ssh no framboesa do meu Chromebook, isso não resolve:

chronos@localhost ~ $ ping raspberrypi.local
ping: unknown host raspberrypi.local
chronos@localhost ~ $ ssh [email protected]
ssh: Could not resolve hostname raspberrypi.local: Name or service not known

Estou faltando alguma coisa? Na verdade, eu posso ssh meu Raspberry Pi de outro cliente (Arch Linux) na minha rede local, então eu acho que o problema deve estar no lado do Chromebook.

Esta é a definição de serviço que estou usando no Raspberry Pi (/etc/avahi/services/ssh.service):

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
        <name replace-wildcards="yes">%h SSH</name>
        <service>
                <type>_ssh._tcp</type>
                <port>22</port>
        </service>
</service-group>

    

Answer 1

O Avahi procura serviços Avahi na lan, e os consulta (em seu exemplo) para mostrar a resolução IP.

O uso do endereço IP no seu Chromebook obtém o resultado que você está procurando (resposta de ping ou acesso ssh).

A maioria das redes não armazena o nome da máquina, apenas o IP. Você pode fornecer sua própria pesquisa de nome de domínio (para adição de ip estático) em /etc/hosts (os chromebooks devem estar no modo de desenvolvedor) adicionando a linha: raspberrypi.local 192.168.1.200

Ou automatizando-o em um script, usando sed para substituir a linha iniciada por raspberrypi.local , com a saída do comando avahi-resolve --name raspberrypi.local . Isso funcionará para alocações IP dinâmicas, mas você ainda precisará executar o script pelo menos uma vez toda vez que o RPi for ligado (no caso dele ser alterado).

O motivo pelo qual você não está obtendo um resultado (que você espera) é porque o serviço de nome de domínio (ou servidor DNS) não sabe sobre os nomes de endereços da LAN.

O seguinte também funcionará:

ping 'avahi-resolve --name raspberrypi.local'
ssh 'avahi-resolve --name raspberrypi.local'

'está na tecla til (~)

    

Answer 2

A maneira normal de oferecer suporte a pesquisas de nome avahi *.local , por isso, só funciona para ping raspberrypi.local via mdns4_minimal in /etc/nsswitch.conf , por exemplo, como descrito em Como configurar a pesquisa de DNS local no Ubuntu 16.10? - Pergunte ao Ubuntu

Parece que isso foi possível no Chrome OS depois que esse bug foi corrigido: 199397 - FR: Resolução de nomes mDNS - chromium - Monorail , mas que funcionou com problemas em algumas redes que usavam seu próprio domínio não mdns .local , conforme descrito em 626377 - Ativa a resolução do nome do host mDNS sem quebrar .local unicast DNS - chromium - Monorail .

A partir do início de 2018, parece que o problema 626377 está próximo do lançamento para reativar as pesquisas de mdns.

Nesse meio tempo, acho que isso pode ser corrigido localmente se você entrar no modo de desenvolvedor e alterar sua partição rootfs. E até então, a resposta de Paul Wratt tem algumas soluções úteis.