2

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.

4
  • Is your Rpi assigned with a public or private IP Address? The former will allow you to directly access to it from outside while the later requires you to configure your NAT router with a designated port for the access. If your Rpi is assigned with a public IP Address, all you need is a Full Qualify Doman Name (FQDN] to represent its public IP Address. An FQDN is usually not free. However, you can get a free FQDN with preassigned domain name from most free DNS out there. I personally use FreeDNS
    – user91822
    Jan 16, 2019 at 12:46
  • @user91822 I'm not trying to access it from outside the network so I shouldn't need to set up port forwarding for it. It is assigned with a local IP address from the router, but this can change and I have no control over it. What I want is for the hostname (raspberrypi.local, for example) to point to the local IP of the Pi so I can access it whilst connected to the same network. I don't need to access it from an outside network and am unable to set up port forwarding anyway. Sorry if my question was unclear. Jan 16, 2019 at 15:40
  • /etc/dhcp/dhclient.conf is not used by a standard Raspbian installation. Your problem is most likely nothing to do with the Pi - most institutions filter local traffic.
    – Milliways
    Jan 16, 2019 at 23:18
  • @Milliways in that case is it possible to set up a DDNS service such as NoIP.com to point to the local ip address of the pi instead of the public address of the network? I dont think this is possible with the commercial DDNS services but is there a method that I could implement here? Jan 17, 2019 at 9:57

2 Answers 2

5

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.

10
  • 1
    This is a really great insight. It's really helpful to understand what's going on so thank you. In light of this, I have read this article to hopefully establish what the hostname actually is. When I run nslookup [Pi IP Address] from windows command prompt, I get the following: Server: dns7.uni.ac.uk Address: X.X.X.X dns7.uni.ac.uk can't find X.X.X.X: Non-existent domain. I have also tried nslookup ls and get the same result. Am I misunderstanding something? Thanks for your help so far. Jan 16, 2019 at 21:48
  • 1
    @NathanielJS I have updated my answer. I haven't studied nslookup but it seems it does not do reverse lookup automagically. Try asking an ip address e.g. 192.168.50.7 with nslookup 7.50.168.192.in-addr.arpa with type PTR or ask for reverse lookup. The eqivalent on a RasPi is dig 7.50.168.192.in-addr.arpa PTR or dig -x 192.168.50.7 or host 192.168.50.7.
    – Ingo
    Jan 17, 2019 at 0:45
  • 1
    thanks for this update. As suggested by your comment I have changed the hostname to try and make this process easier. What follows is the output from the terminal when I run the commands mentioned in your answer: nat@NatsPi3:~ $ hostname returns NatsPi3 nat@NatsPi3:~ $ hostname --domain returns nothing. nat@NatsPi3:~ $ hostname --fqdn returns NatsPi3 nat@NatsPi3:~ $ hostname --all-ip-addresses returns 10.3.219.195 Should I try with a fresh raspbian install to see if I get different results? Jan 17, 2019 at 9:53
  • 1
    I think I may have finally got to the bottom of the problem. After a few emails back and forth to the network managers, they finally told me that accessing devices via hostname because of a number of security measures we have on the University's Wi-Fi network and that since I have successfully connected the Pi to the network, they are unable to give me any further information. I'm not sure where to go from here. If there's nothing else I can do I'll mark your answer as the solution as it was the most helpful in understanding the problem. Jan 22, 2019 at 15:38
  • 1
    @NathanielJS I don't believe the story about security issues. It seems they are simply not be able to manage it. I know universities that have policies and howtos for this. If you mostly get the same ip address by DHCP from your uni (the default by DHCP) you may consider to use a static entry in the /etc/hosts file.
    – Ingo
    Jan 22, 2019 at 18:58
0

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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