If OctoPrint tells you it can't install plugins or perform updates or such due to your OctoPrint instance not being connected to the internet, but you are 100% certain that it in fact is (e.g. you can ping external addresses when logged into your OctoPrint server), it could be that the host and IP you have configured for performing the connectivity check or the name resolution are the problem here.
OctoPrint by default uses Google's DNS server at 8.8.8.8 on port 53 for its connectivity check, which should usually be always reachable, but your network might be filtering access. It also checks whether it can resolve octoprint.org against the DNS server configured for its network (note that this will NOT automatically be the same that you perform the connectivity check again but rather whatever your network assigns your server to use, or whatever you have manually configured at OS level!).
Go into Settings > Server > Connectivity check and test whether the server entered there is reachable and the name resolves. Try entering an alternative host. If push comes to shove you can also disable the connectivity check here, making OctoPrint just always assume that it can reach the internet.
Thank you! This resolved a very frustrating issue I've been having with my install of OP. After disabling the connectivity check, OP performed a successful update check and I'm behind by two versions. Now I need to figure out why my RPi3 can't "see" 8.8.8.8:53.
Why does octoprint default to Google's DNS server address here instead of using the one provided by the DHCP server it is connected to or the one defined in /etc/resolv.conf?
Because the one configured in the system might be a local one and thus cannot be used for checking online connectivity (being able to open a connection to a local ilhost says nothing about being able to reach out into the WAN). And the one by Google is highly available (contrary to some open ones). But as said, you can just configure your own during setup.
This might be related: Two users of the ngrok plugin reported that their tunnel was not being created on start of OctoPrint. Inspecting their logs, I could see that some plugins (including the software update plugin) are having trouble connecting to their services during startup but then function fine after start up:
Could be a name resolution issue (which is why 1.4.1 will also check if it can actually resolve a hostname, not just if it can reach an external IP). Have seen that occasionally in the past in logs from others, have never seen it in my own so far. Another possible cause for trouble reaching external endpoints right after bootup can be a delay in NTP updates (ran into that on a fresh flash in my test automation, which is why that will now wait for NTP syncs).
It might be a solution for the Connectivity check to try again after a short pause. This admittedly somewhat icky workaround fixes the issue in the ngrok plugin.
Since I had no way to reproduce the issue or test a workaround other than implementing a retry, I went for a 20 second period in ngrok. Users report that fixed their issue. I don't like that "magic number", and I could see if the users are open to experiment with different periods, but my gut feeling is that 3 seconds might not cut it.
I'm guessing these connectivity problems only occur just after a reboot. Perhaps a standalone script executed out of rc.local could try for 20 seconds to give the network time to settle down.
Wouldn't it make sense to react to ConnectivityChanged event rather than depending on startup @fieldOfView? You could also then handle dropped connections, etc.
Just wanted to point out something that wasn't 100% obvious to me reading the above. OctoPrint's connectivity check is not a DNS request.
TL;DR: You can use any highly available website as the connectivity check, or any other port that answers. 80, 443, whatever. I ended up using 1.1.1.1 port 80
Long version:
Why does this matter? It only matters if you have restrictive rules on your firewall and you or whoever runs the firewall doesn't want to open them up. I run a local DNS server, setup everything to use that via DHCP, and block all outgoing access to ports 53 and 853. I don't want to have an exception just for the OctoPrint connectivity check. So, I picked 1.1.1.1 port 80. 1.1.1.1 is CloudFlare's alternative to Google's 8.8.8.8. But, unlike 8.8.8.8 there is a webserver that answers a 1.1.1.1:80. OctoPrint doesn't actually do an HTTP request, it just tries to connect to port 80.
Another thing that may concern some people is that you may be worried about 8.8.8.8 snooping on what DNS queries you make, in this case, OctoPrint isn't making a DNS request, so there's nothing to log beyond your public IP address that everything you connect to can see. OctoPrint DOES do a DNS query for the "resolve a hostname" portion of the check, but from what I can tell, that portion of the check uses the regular system configured DNS servers.
My RasPi is now in an IPv6 only network - looks like I can only enter a legacy IP (also known as IPv4) address into "host ip" - any chance for an update? (feature request)?
Had this same issue so posting my cause here in case someone stumbles across this older post.
For me the cause was conflicting IP due to the lack of an IP reservation on the router. Octoprint server was offline when another device connected and received the same IP. Resolution was giving the new device a different IP on the router, and locking the IP for my Octoprint back to what it expected.
