Cannot resolve local hostname of my Raspberry Pi

Question

Currently I am using a pi 3 model B+ as a mopidy server. I set this up at home and I was able to access the pi with the hostname from a browser (e.g. going to http://hostname.local/ in a browser). I am now back at uni and for some reason when I try the same http://hostname.local/, I get a message saying that the IP address cannot be found. Since I am at uni I am very restricted with what I can do. Many solutions involve setting up a static IP, which I cannot do since I cannot access the router config.

I am using avahi-daemon for the mDNS service.

As a side note, I can still access the pi by navigating to http://X.X.X.X/ (where X.X.X.X is the pi's IP). However this can be annoying since I need to connect with VNC (Since I have enabled cloud access) to find what the pi's IP is.

Things I have tried:

• send host-name = gethostname(); to send host-name = "hostname.local.net" in dhclient.conf
• Changing nameserver X.X.X.X in /etc/resolv.conf to nameserver 8.8.8.8. However, on every reboot this value is removed and replaced by 3 separate nameserver values. This file also includes domain [DOMAIN].ac.ukat the top. I'm not sure how relevant that is.

Other things that may be worth noting:

• I am not using Ethernet, I am using a WiFi connection. The WiFi network uses WPA2-Enterprise AES, with PEAP authentication (EAP-MSCHAP v2). The password for the network is not stored in plaintext in wpa_supplicant.conf, but is stored as a hashed value.

This question has been asked a lot but I have decided to ask specifically about my case since I cannot find solutions that work in my circumstances. I am not sure whether I just need to update a value somewhere since I have moved to a different network or not.

Any help is greatly appreciated.

EDIT

It may go without saying but on the Pi that I am trying to configure, I am able to run the command ping pihostname and ping pihostname.local successfully, and the correct IP is pinged.

Answer 1

To understand what's going on here is to know something about link-local addresses and how avahi handles it. If there is a mostly small home network without a DHCP server then avahi configures a link-local ip address from the reserved address block 169.254.0.0/16 to the interface. It also maps this ip address to the name hostname.local. The DNS domain .local is explicit also reserved for link-local addresses and is never managed by any DNS server.

Configuring a link-local address is the last way to set an ip address. Any other method will overlay this, e.g. a static ip address or configuration by a DHCP server. It seems at home you do not have a DHCP server running so avahi will configure a link-local address that you can address with hostname.local. At the uni there is a DHCP server running as usual for bigger networks so you do not get a link-local address. Instead you should get an ip address from the DHCP server with all needed configuration options like DNS server address and maybe the dns domain of the uni, e.g. uni.net so you should be able to address your RasPi with hostname.uni.net. This naming is correct because your RasPi is on a different network and DNS has unique names all over the world for different locations. You cannot use the same full qualified DNS name for your home network and the uni network, but only the hostname.

All this should work out of the box with a default unmodified Raspbian Stretch image. Don't fiddle with static ip addresses. It will break all mobile configuration attempts. Let avahi and DHCP do its work.

Update in respect of the comment for name resolution.
We are talking about Raspberry Pi and we try to connect it to the uni network. So I will reference it. For name resolution there is mostly used DDNS (Dynamic Domain Name Service). A host connected to a network will send its hostname to the DHCP server that updates the DNS database with the hostname. The problem now is that many students carry their Raspberry Pi to the uni and don't change the default hostname. So you have many hostnames raspberrypi. The DHCP server will manage to give any raspberrypi a different ip address, that's not the problem. The problem is that you don't have a unique hostname. Instead you have one raspberrypi with many ip addresses if you ask DNS. It is up to the network management how it handles it. A common solution is that the DHCP server gives a unique hostname to the RasPi with its options and it will take care that it gives always the same name to the same RasPi. You can ask the network management how they handle this and you should configure dhcpcd to accept all this. If this all is to complex then just fall back to use the ip address. You get this with hostname, e.g.:

rpi ~$ hostname
raspberrypi
rpi ~$ hostname --domain
home.hoeft-online.de
rpi ~$ hostname --fqdn
raspberrypi.home.hoeft-online.de
rpi ~$ hostname --all-ip-addresses
192.168.50.182

If in daubt with the ip address then look with ip addr.

Answer 2

The answer I wish I had known 4 years ago...

For anyone finding this question years later, the solution I wish I had known about at the time was ZeroTier.

For me it completely solves the issue I was having, as it will allow you to assign a "virtual" IP address of your choosing to the Pi and your PC, and access them on a sort of virtual network, as if they were on a LAN. This way any time the Pi and PC have internet access, they can address each other with this "virtual" IP address which will never change, even if they are assigned different IP addresses on the LAN. This also has the added benefit of being able to access your devices when you are not on the LAN, but that wasn't relevant to my needs at the time.

ZeroTier is P2P, so in theory it should be much faster than something like a VPN (Which wouldn't have helped anyway since I would need a static IP), and since you can set each device's IP from a web interface, you don't have to rely on the Pi only being assigned a couple of different IP addresses and randomly trying them. The downside is it seems to slow your connection down (see below), but for applications like I was talking about, it wouldn't have had an impact.

Speed Impact

Running iperf3 on a LAN IP

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   111 MBytes   931 Mbits/sec    0    365 KBytes
[  5]   1.00-2.00   sec   110 MBytes   923 Mbits/sec    0    365 KBytes
[  5]   2.00-3.00   sec   105 MBytes   879 Mbits/sec    0    365 KBytes
[  5]   3.00-4.00   sec   110 MBytes   923 Mbits/sec    0    365 KBytes
[  5]   4.00-5.00   sec   109 MBytes   917 Mbits/sec    0    365 KBytes
[  5]   5.00-6.00   sec   107 MBytes   896 Mbits/sec    0    365 KBytes
[  5]   6.00-7.00   sec   109 MBytes   918 Mbits/sec    0    365 KBytes
[  5]   7.00-8.00   sec   109 MBytes   918 Mbits/sec    0    365 KBytes
[  5]   8.00-9.00   sec   110 MBytes   924 Mbits/sec    0    365 KBytes
[  5]   9.00-10.00  sec   110 MBytes   922 Mbits/sec    0    365 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.07 GBytes   915 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.06 GBytes   914 Mbits/sec                  receiver

Running iperf3 to the ZeroTier IP

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  19.3 MBytes   162 Mbits/sec    0    223 KBytes
[  5]   1.00-2.00   sec  19.6 MBytes   164 Mbits/sec    0    223 KBytes
[  5]   2.00-3.00   sec  19.3 MBytes   162 Mbits/sec    0    223 KBytes
[  5]   3.00-4.00   sec  19.7 MBytes   165 Mbits/sec    0    223 KBytes
[  5]   4.00-5.00   sec  19.2 MBytes   161 Mbits/sec    0    223 KBytes
[  5]   5.00-6.00   sec  16.8 MBytes   141 Mbits/sec    0    223 KBytes
[  5]   6.00-7.00   sec  19.6 MBytes   165 Mbits/sec    0    223 KBytes
[  5]   7.00-8.00   sec  19.5 MBytes   163 Mbits/sec    0    223 KBytes
[  5]   8.00-9.00   sec  19.8 MBytes   166 Mbits/sec    0    223 KBytes
[  5]   9.00-10.00  sec  19.7 MBytes   165 Mbits/sec    0    223 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   193 MBytes   162 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   192 MBytes   161 Mbits/sec                  receiver

The pros can outweigh the cons

For my situation, I didn't need 900 Mbits/sec as I was just running a web interface. ~100 Mbits/sec would have been more than adequate, and would have meant that I could access the Pi with a fixed virtual IP no matter what IP it was assigned on the LAN. For that reason I think it is valuable to know about.

Addendum

I do not want to discredit @Ingo's answer, as they provided a lot of helpful insight into the issue I was facing. However, I do want to bring attention to the solution that I could've really used at the time, as I'm seeing a lot of views of this question recently. If this answer helps just one kid...