4

I have a raspberry pi (raspbian jessie) with ssh & vnc services registered in avahi. I can see both services in my client (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 = []

And it seems that I can resolve both the name and the address:

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

But whenever I try to ping or to ssh the raspberry from my chromebook, it would not resolve:

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

Am I missing something? I can actually ssh my Raspberry Pi from another client (Arch Linux) in my local network, so I guess the problem should be on the Chromebook side.

This is the service definition that I'm using in the 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>
1

Avahi looks for Avahi services on the lan, queries them to (in your example) show IP resolution.

Use of the IP address on your chromebook will get the result you are looking for (ping reply or ssh access).

Most networks do not store the machine name, just the IP. You can provide your own domain name lookup (for static ip addess) in /etc/hosts (chromebooks must be in developer mode) by adding the line: raspberrypi.local 192.168.1.200

Or by automating it in a script, using sed to replace the line begining with raspberrypi.local, with the output of the command avahi-resolve --name raspberrypi.local. That will work for dynamic IP allocations, but you will still need to run the script at least once everytime the RPi is powered on (in case it changes).

The reason you are not getting a result (that you expect) is because the domain name service (or DNS server) does not know about LAN address names.


The following will also work:

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

` is on the tilda key (~)

  • Thanks for the workarounds. Note that the domain name service can be configured to do these lookups, and that is normally how e.g. Ubuntu is configured when avahi is installed, as described in my answer. – nealmcb Apr 5 '18 at 16:39
0

The normal way to support avahi *.local name lookups so it just works to ping raspberrypi.local is via mdns4_minimal in /etc/nsswitch.conf e.g. as described at How to configure local DNS lookup in Ubuntu 16.10? - Ask Ubuntu

It seems that this was possible in Chrome OS after this bug was fixed: 199397 - FR: mDNS name resolution - chromium - Monorail, but that ran in to problems on some networks which used their own non-mdns .local domain, as described at 626377 - Enable mDNS hostname resolution w/o breaking .local unicast DNS - chromium - Monorail.

As of early 2018, it seems that issue 626377 is nearing release to re-enable mdns lookups.

In the meantime I guess that this can be fixed locally if you get into developer mode and change your rootfs partition. And until then, the answer by Paul Wratt has some helpful workarounds.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.