Further Link does not work most of the time

I have to go through programs on Further.pi-top.com about 10 times, but connecting to my device worked about 1 or 2 times only. I have gone through the KB article on how to connect and I even changed the DNS nameserver in resolv.conf to be:
nameserver 1.0.0.1
nameserver 1.1.1.1

But connecting to the pi-top robot still does NOT work.

It is really frustrating.

Any suggestions?

Thanks.

hi @designcode,
Have you had a look at this article on our knowledge base? Can you try it and let me know if you still have problems?

Hi, Yes, as mentioned above I have gone through the Knowledge Base (KB) article. And per the KB article I had put 1.0.0.1 and 1.1.1.1 for DNS servers in the resolv.conf.

This issue has allowed me to connect to the robot only twice so far. The other 8 times the connection was refused. And I have done all software updates. In fact, I do software updates as soon as I start the Pi-Top. But that makes me wonder if the software update changed a configuration that prevents the connection.

Any suggestions?

Thanks,
GH.

Hi @designcode,

I’m a developer of Further Link and I’d like to help work out what issue you’re having. I’ll ask you to provide some information to diagnose the problem.

Are you using the Further website from the browser on your pi-top, or from another computer?
What browser are you using to access the Further website?

If you are using Further from your pi-top you can type ‘localhost’ in place of the pi-top’s IP address. If you are trying to connect from another computer and have the green cable that comes with pi-top 4 complete, try using that cable to connect the pi-top to a usb type A port on your computer, and use 192.168.64.1 as the connection IP.

If this helps the issue may be in making connections across your local network.

If this doesn’t help I’d like you to run these terminal commands on your pi-top and provide the output:

  • sudo systemctl status further-link.service
    This shows the status of the Further Link server. It should show that it is active (running) and will be some logs that could contain information on an issue. If the service is not running, try starting it through the pi-top miniscreen as described in the KB article mentioned above.

  • apt-cache policy pt-further-link
    This shows the installed and available versions of Further Link, which may help to reproduce your problem.

  • getent hosts 127-0-0-1.further-link.pi-top.com
    This performs a DNS lookup to confirm you can access the domain names used to make Further Link connections. If you have no output from this command it would indicate you need to configure alternative DNS resolver such as Cloudflare, though this is not necessary on most networks.

Hello @angus: apologies for the late reply. I was waiting to receive the Pi-Top hdmi cable so I can use the monitor.

Anyway, this command shows that the further-link.service is NOT running. However, the pt-futher-link.service is ACTIVE.
sudo systemctl status further-link.service
Per the instructions on this page, the pt-further-link.service is what is needed. And that is why I only checked that this service is running.

Which service should be ACTIVE pt-further-link or futher-link?

pi@pi-top:~ $ apt-cache policy pt-further-link
pt-further-link:
Installed: 4.4.5
Candidate: 4.4.5
Version table:
*** 4.4.5 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
100 /var/lib/dpkg/status
4.4.4 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
4.3.1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
4.2.1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
4.2.0 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
4.1.0 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
4.0.2 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
3.3.1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
3.1.2 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
3.1.1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
3.1.0 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
2.1.2-3 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
2.1.2-1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
2.0.0-2 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages
2.0.0-1 500
500 http://apt.pi-top.com/pi-top-os sirius/main armhf Packages

pi@pi-top:~ $ getent hosts 127-0-0-1.further-link.pi-top.com
127.0.0.1 127-0-0-1.further-link.pi-top.com

Today I was able to connect to my Pi-Top via Futher site after doing the following:

  1. Changing the DNS per this site:
    https://developers.cloudflare.com/1.1.1.1/setup-1.1.1.1/linux
    to be:
    1.1.1.1
    and
    1.0.0.1
    in
    /etc/resolv.conf

Question on why this connection to the Pi-Top only works some times:

Could it be that the resolv.conf file is being reset every time there is a system update and that is why the connection works sometimes and sometime not?
Note: I believe that I have set those IP’s in the past in resolv.conf but some process has changed them back to default.

Thanks,
G. Hariz.

Hi @angus: Yesterday, I could connect to the Pi-Top on Further. So I kept the Pi-Top4 ON all night to see if I can still connect today without having to make any changes.

However, today it does NOT connect (on the Further website for Alex Robot we see a Connection Error - cannot connect to your pi-top.

So I checked the contents of resolv.conf today (please see below). It seems that some process has changed the contents of resolv.conf so the nameservers are no longer set 1.0.0.1 and 1.1.1.1 as I set them manually yesterday.

Generated by resolvconf

domain home
nameserver 192.168.0.1
nameserver 2a02:908:2:a::1
nameserver 2a02:908:2:b::1

What is the solution to the problem of resolv.conf being reset by a system process?

Thanks,
G. Hariz

Hi @designcode,

Yes, pt-further-link is the correct service name, I made a typo so I’ll correct that now above.

Ok, so it seems your issue is with the DNS resolution, and now specifically in keeping Cloudflare DNS configured.

It is normal for the resolv.conf file to be updated by system services so it’s unfortunate Cloudflare’s instructions don’t address this. I might make a suggestion to them to improve this.

I’m not particularly knowledgeable on this area so I might refer you to this official documentation

However, I will also provide a solution they don’t mention that has worked for us on pi-top in the past, which is to add the nameserver configuration lines to a different file, /etc/resolv.conf.head, instead.

You can run this command to add the Cloudflare server config to the file:

echo "nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001" | sudo tee /etc/resolv.conf.head

After this you should reboot to have the config reloaded.

Here are some links related to that solution, some also refer to alternate files that may work:


Hello @angus,

Adding the DNS servers to ```
/etc/resolv.conf.head

seems to have done the trick.

Thanks,
GH.