[Solved] Cannot install Octoprint due to network issues but network is working

Today I just flashed and updated the latest image of Dietpi on a Raspberry Pi 3B+. Everything went fine but cannot install Octoprint from the software optimized. I get an error like dietpi cannot reach the octoprint gihub repository url but network is correctly working.
The raspberry pi is connected through ethernet to the router and I can check/download updates without any issues.

This is the screen I always get when attempting to install Octoprint:

Garret
Thanks for your report. Will check here.

EDIT

Hmm works great here:

root@VM-Stretch:~# G_CHECK_URL > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer!
[ OK ] Connection test: > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer!

What happens if you try the above (outside of dietpi-software)?
Which DNS server do you use? cat /etc/resolv.conf

Giving G_CHECK_URL https://github.com/foosel/OctoPrint.git returns the same window I showed you in my first post. For some strange reasons it seems it cannot reach the url.

While giving the cat command I get the dns server of my router which I then set with the google ones (8.8.8.:sunglasses:

root@livingroom:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
root@livingroom:~#

I tried to reach the repository with the curl command and this was the result:

root@livingroom:~# curl https://github.com/foosel/OctoPrint.git
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
root@livingroom:~#

I don’t understand. I tried to install other programs via the software optimized and they installed without any problem.

Garret
The curl output is expected, host resolution worked fine with the Google DNS.
You can verify again with G_CHECK_URL, I am pretty sure it works as well.

So in this case I would check your routers DNS settings, if it actually serves as DNS server and which uplink DNS server it uses itself. You could then also try to use the configured uplink DNS server from your router directly, perhaps this is/was temporarily or permanently down or faulty.

Hmm I tried again this morning but I get always the same window with the same error.

If I connect from my phone to the router via wifi, I can access that url. I have DHCP set up in the router and the google dns as primary and secondary dns. I tried to switch the google dns on my router with the cloudfare (1.1.1.1), rebooted the router and raspberry pi and still get the same error.

That is so weird…

Did you verify that the Pi adapts the cloudflare DNS from the router after connecting (via DHCP)?
Note that any DHCP lease in most cases overwrites /etc/resolv.conf. It is a dynamically created file, controlled by resolvconf package which can be triggered by different sources, e.g. DHCP clients.

What you could try as well is use a static IP instead of DHCP and hard code the DNS server there. If the static IP is within the DHCP IP range and as well configured as reserved for the Pi in the router network settings, this should work well in most cases. This is how I do it here :wink:.

Just to be sure, you don’t have Pi-hole installed, do you?

I (partially :cry: ) solved the problem by installing octoprint manually. It is so weird that when using the dietpi-software it cannot clone the git repository but if I give the command manually it works without any issues. There must be something wrong with the dietpi-software, like it connects using some other network configuration for some reason.

This was the procedure I used on a clean dietpi installation:

su dietpi  #octoprint needs to be later started by non-root user
cd
sudo apt-get install git python-pip virtualenv
git clone https://github.com/foosel/OctoPrint.git
cd OctoPrint/
virtualenv venv
./venv/bin/python setup.py install
./venv/bin/octoprint  #starting of octoprint

Can you suggest an easier way to install it and have it always running when I restart dietpi? And still it would be really nice to have it installed through the software optimized… :roll_eyes:

Garret
Can you please try: G_CHECK_URL https://github.com/foosel/OctoPrint.git
So we see if wget and even our wrapper works outside of dietpi-software.

Hi MichaIng, thank you a lot for your message. As I said in my previous post, I had already tried that command and gives me back exactly the same error window :cry:
But I tried it again this morning and I got the same result. I really don’t understand…

Okay, I have no idea why this fails in your case while it works well in other cases, especially since git clone works fine in your case as well.

You can try the naked: wget --spider https://github.com/foosel/OctoPrint.git

However aside from that to allow you installing OctoPrint via DietPi-Software, please open /DietPi/dietpi/dietpi-software, find the line with https://github.com/foosel/OctoPrint.git and remove the G_CHECK_URL “$INSTALL_URL_ADDRESS” below.

This skips the online check which is not required if you already know that git clone works.

Giving the wget command I get this:

root@transmission:~# wget --spider https://github.com/foosel/OctoPrint.git
Spider mode enabled. Check if remote file exists.
--2019-03-10 19:19:08--  https://github.com/foosel/OctoPrint.git
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/foosel/OctoPrint [following]
Spider mode enabled. Check if remote file exists.
--2019-03-10 19:19:31--  https://github.com/foosel/OctoPrint
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

root@transmission:~#

In any case, thank you for the other solution of skipping if the git repository can be reached :slight_smile:

Garret
Very strange, resolving the github.com hostname times out with G_CHECK_URL but works with plain wget --spider.

The only thing I can imaging that the timeout value we use (5 seconds) is too short.
Please try:

timeout=10 G_CHECK_URL https://github.com/foosel/OctoPrint.git

Or even with higher value.

Ah I see 19:19:08 and 19:19:31 as timestamps (so 23 seconds) in your error output, which is indeed veeery long.
See my output which didn’t even take 1 second:

root@VM-Stretch:/mnt# wget --spider > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer!
Spider mode enabled. Check if remote file exists.
–2019-03-10 19:42:15-- > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer!
Resolving github.com (github.com)… 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443… connected.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer! > [following]
Spider mode enabled. Check if remote file exists.
–2019-03-10 19:42:15-- > GitHub - OctoPrint/OctoPrint: OctoPrint is the snappy web interface for your 3D printer!
Connecting to github.com (github.com)|192.30.253.112|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled – not retrieving.

Which DNS server do you use? I guess this step took so long?: Resolving github.com (github.com)… 192.30.253.112, 192.30.253.113
If you have a router that can serve as DNS server for your local network (most do), please try to use it. You could do a quick test by adding the routers IP to /etc/resolv.conf, e.g. (in my case): echo ‘nameserver 192.168.178.1’ > /etc/resolv.conf
If you use DHCP from the router, it should apply itself automatically as DNS server, otherwise you could try to use the DHCP service IP etc as static IP and then add the router IP as static DNS entry as well.

With timeout=10 I still get the error but when increasing to 60 seconds it passes the test.

I am using DHCP on my router and I have given a static ip to the raspberry pi. The router has google dns as primary dns and cloudfare as second dns.

Garret
Hmm do other devices in your local network as well need that long to connect to www resources? It depends on your location as well of course, but also Google DNS should be way faster since it is a mirror director that redirects to the closest actual server location near you.

I am using DHCP on my router and I have given a static ip to the raspberry pi.

Do you mean you enabled static IP use on the Pi or you made your router assigning a “reserved” IP to the Pi, still via DHCP?

I have a 70mbit connection both download/upload and I think every webpage and download is quite fast.

Before I meant that the router assigns a static ip to my raspberry pi.

And connecting e.g. via browser to https://github.com/foosel/OctoPrint.git works quickly?
Does curl https://github.com/foosel/OctoPrint.git work faster than the wget?

Ahhhh wait do you have IPv6 enabled or disable? If enabled did you choose to prefer IPv4?
Could you try:
G_CONFIG_INJECT ‘prefer-family[[:blank:]]=’ ‘prefer-family = IPv4’ /etc/wgetrc
And check if the wget --spider command is faster now?

root@transmission:~# G_CONFIG_INJECT 'prefer-family[[:blank:]]=' 'prefer-family = IPv4' /etc/wgetrc
[  OK  ] G_CONFIG_INJECT | Desired setting in /etc/wgetrc was already set: prefer-family = IPv4

root@transmission:~# wget --spider https://github.com/foosel/OctoPrint.git
Spider mode enabled. Check if remote file exists.
--2019-03-11 08:53:57--  https://github.com/foosel/OctoPrint.git
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/foosel/OctoPrint [following]
Spider mode enabled. Check if remote file exists.
--2019-03-11 08:54:17--  https://github.com/foosel/OctoPrint
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

root@transmission:~# curl https://github.com/foosel/OctoPrint.git
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

root@transmission:~#

Garret
Ah okay IPv4 was already preferred. I just remembered that on my VMs connecting to IPv6 addresses took a very long time before wget (and APT as well) gave up and switched to IPv4.

I mean theoretically you could try to use the IPv6 address instead and compare:
wget --spider -6 https://github.com/foosel/OctoPrint.git

Did the curl command finish quickly?
Ah and to better compare, curl should follow redirects.

So overall testing would be:

time curl -L https://github.com/foosel/OctoPrint.git
time wget --spider https://github.com/foosel/OctoPrint.git
time wget --spider -6 https://github.com/foosel/OctoPrint.git

MichaIng here are the results: :slight_smile:

root@transmission:~# time curl -L https://github.com/foosel/OctoPrint.git
[...]
real    0m16,955s
user    0m0,119s
sys     0m0,011s

root@transmission:~# time wget --spider https://github.com/foosel/OctoPrint.git
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:00:37--  https://github.com/foosel/OctoPrint.git
Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/foosel/OctoPrint [following]
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:01:08--  https://github.com/foosel/OctoPrint
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.


real    0m39,830s
user    0m0,127s
sys     0m0,010s

root@transmission:~# time wget --spider -6 https://github.com/foosel/OctoPrint.git
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:06:52--  https://github.com/foosel/OctoPrint.git
Resolving github.com (github.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘github.com’

real    0m20,096s
user    0m0,065s
sys     0m0,009s

root@transmission:~#

Okay there is not IPv6 address for this github.com.

I am still totally wondering. All of those commands take a veeery long time. In my case all of them finish in a fraction of a second.

Something with your network setup must be wrong. Lets check if other GitHub resources and other hosts take as well that long:

time wget --spider https://github.com/MichaIng/DietPi.git
time wget --spider https://dietpi.com

Did you try to open https://github.com/foosel/OctoPrint.git in a browser from a desktop within the same local network? Does it open immediately or take as well so long?