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

[Garret]

@MichaIng I have to say that on this Rasperry pi 3B I have home assistant, wireguard, docker with a transmission container, jackett, radarr and sonarr. They all work well. never had issues but they could hamper the connection?

When loading the octoprint github page on another terminal I never noticed any slowing down.

Anyways, these are the results from what you asked:

Code: Select all

root@transmission:~# time wget --spider https://github.com/MichaIng/DietPi.git
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:36:57--  https://github.com/MichaIng/DietPi.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/MichaIng/DietPi [following]
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:37:12--  https://github.com/MichaIng/DietPi
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.


real    0m16,280s
user    0m0,135s
sys     0m0,021s

root@transmission:~# time wget --spider https://dietpi.com
Spider mode enabled. Check if remote file exists.
--2019-03-11 16:37:48--  https://dietpi.com/
Resolving dietpi.com (dietpi.com)... 104.27.178.199, 104.27.179.199, 2606:4700:30::681b:b3c7, ...
Connecting to dietpi.com (dietpi.com)|104.27.178.199|: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    0m0,321s
user    0m0,130s
sys     0m0,041s

root@transmission:~#

[MichaIng]

@Garret
As the issue was during DietPi-Software run, it cannot be related to the other processes, since those were stopped (besides WireGuard).

Also now that I see the usual quick response from dietpi.com it seems to be indeed limited to github.com.

Two last tests to check with one redirection less and raw file access:

Code: Select all

time wget --spider https://github.com/Novik/ruTorrent
time wget --spider https://raw.githubusercontent.com/Novik/ruTorrent/master/index.html

[Garret]

@MichaIng here the results:

Code: Select all

root@transmission:~# time wget --spider https://github.com/Novik/ruTorrent
Spider mode enabled. Check if remote file exists.
--2019-03-11 17:02:04--  https://github.com/Novik/ruTorrent
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... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.


real    0m16,924s
user    0m0,091s
sys     0m0,023s

root@transmission:~# time wget --spider https://raw.githubusercontent.com/Novik/ruTorrent/master/index.html
Spider mode enabled. Check if remote file exists.
--2019-03-11 17:02:31--  https://raw.githubusercontent.com/Novik/ruTorrent/master/index.html
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.84.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.84.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14009 (14K) [text/plain]
Remote file exists.


real    0m0,334s
user    0m0,091s
sys     0m0,009s
root@transmission:~#

[MichaIng]

Very interesting. So raw.githubusercontent.com doesn't cause that delay in your case.

Could you identify which step on github.com takes so long, is it the:
Resolving github.com (github.com)...
or:
Connecting to github.com (github.com)|192.30.253.112|:443...
?

I mean again it could be tested to skip name resolution by calling the IP directly:
time wget --spider 192.30.253.112

[Garret]

Giving the last command it was very fast in getting a response:

Code: Select all

root@transmission:~# time wget --spider 192.30.253.112
Spider mode enabled. Check if remote file exists.
--2019-03-11 18:31:32--  http://192.30.253.112/
Connecting to 192.30.253.112:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://192.30.253.112/ [following]
Spider mode enabled. Check if remote file exists.
--2019-03-11 18:31:32--  https://192.30.253.112/
Connecting to 192.30.253.112:443... connected.
The certificate's owner does not match hostname ‘192.30.253.112’

real    0m0,631s
user    0m0,090s
sys     0m0,009s
root@transmission:~#

[MichaIng]

Ah I also forgot to add the subpath and to ignore cert issues, since the raw IP does not match the hostname which is allowed for the certificate:
time wget -spider --no-check-certificate https://192.30.253.112/Novik/ruTorrent

Will do some web search if there are more users where accessing github.com takes longer than expected.

[Garret]

Code: Select all

root@transmission:~# time wget --spider --no-check-certificate https://192.30.253.112/Novik/ruTorrent
Spider mode enabled. Check if remote file exists.
--2019-03-11 19:06:28--  https://192.30.253.112/Novik/ruTorrent
Connecting to 192.30.253.112:443... connected.
The certificate's owner does not match hostname ‘192.30.253.112’
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/Novik/ruTorrent [following]
Spider mode enabled. Check if remote file exists.
--2019-03-11 19:06:29--  https://github.com/Novik/ruTorrent
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... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.


real    0m16,338s
user    0m0,111s
sys     0m0,000s
root@transmission:~#

[MichaIng]

So from what I can see, it is indeed the name resolution that takes so long. Connecting to the IP itself took a second, but after redirection to hostname it took again ~15 seconds.

Did you try to switch to static IP (using the IP address that you already had assigned from DHCP, via dietpi-config > Network Options: Adapter) and use e.g. Google DNS (8.8.8. as static DNS server?

[Garret]

Honestly I confess I am a little bit tired
I have all my other devices connected to the router in the same way and I can see they are using the google dns. I do not see why the raspberry with dietpi should do something different.

Thank you very much @MichaIng but in any case the issue is solved despite it will remain a mystery. I have many other installations in this raspberry pi and I would avoid to change network options though they should still keep the system safe.

Again, thank you very much for your support!

[MichaIng]

Jep understandable. So just keep this in mind in case you face the a connection test issue (G_CHECK_URL from any of our scripts) again. It seems to be only github.com and due to the many tests indeed the DNS resolving of this particular hostname that takes much more time than usually.

I will also keep this in mind in case of similar reports. In case when checking a GitHub resource we need to check that via raw.githubusercontent.com instead of github.com which leads to the same desired result (repo available or not) but without the issue in your case.