What is the problem?
I recently bought and set up a Pi 4B for OctoPrint usage. The setup process has been pretty seemless, but I've started running in to problems with maintaining SSH sessions to the Pi from inside my network. For reference, it's running on WiFi
So... I've got both a problem and a question. I'll start with the question...
I know what the IP address is internally for my Pi. I can ping the IP and it responds. However, when I ping the hostname, it returns with an IP that's outside of my network. Is that normal?
The issue I'm having is with inconsistent network connection. The quality is -55db. So, I know I'm well within range of the router (which is a Netgear Orbi RBR50 for reference). I keep loosing connection and having slow response over SSH. Ping tests show similar results with clusters of dropped packets every couple of minutes.
What did you already try to solve it?
On the advice of a similar thread for general Raspbian support, I disabled IPv6 on all interfaces on the Pi (tried to disable at the router, but couldn't find a setting) and can confirm that IPv6 is disabled, but it's made no difference.
I also checked the signal quality and moved the Pi around to confirm it's not the location of the device that's causing the issue.
Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)
RPi4B 4GB model running latest OctiPi release
Connecting to Netgear Orbi RBR50
My internal IP network scheme starts is 10.10.96.x and is set up to be a class C network.
I can ping the Pi's assigned IP and it responds with about a 10-15ms response time. If I try to ping the hostname it responds with about a 50ms average response time at something along the lines of 128.x.x.x.
It makes absolutely no sense to me. It's almost like it's routing out of my network and then back in, but I can't explain why it would do that. I haven't done anything to my router to make it externally accessible or to the Pi itself to register to a third party external service.
As far as the internal network inconsistency, I'm hosting a mesh wireless system that's combination 2.4 and 5GHz. I got to doing some thinking last night and checked it this morning... It's bouncing back and forth between the two wireless bands and I think that's probably the problem. I'm going to have to do some poking to see if I can force it to single band only.
For reference, it returns with an IP of 23.195.69.111. I did a tracert of the IP and it's definitely outside of my network.
Also, the Pi is definitely loosing network connection when it hops to 5GHz and then resumes when it switches back to 2.4. I don't understand why that's happening though.
So when you ping by IP address the machine from which you are pinging doesn't do a DNS lookup for your Pi, but when you ping by name, it does. If you have a local DNS server on your internal network, the order of DNS servers is broken - your local one should be first, and the external one second. Better still, your local internal DNS should handle all of your DNS lookups, including ones for devices on the internet.
The best place to find the Pi's IP address is your DHCP server - probably your ISP's router.
I disable DHCP on my router and run an instance of dnsmasq on another Raspberry Pi, dnsmasq handles DNS lookups and DHCP. I allocate IP addresses not at random but by using the client name [the octoprint Pi's name] and give the Pi the same address every time it boots. Generally the Pi would always get the same IP from the dnsmasq cache, but I prefer to control what IP address the Pi gets.
I would definitely try making the Pi use 2.5GHz only, it could be the 5GHz signal isn't consistently strong enough to maintain a connection. Better still, use a Cat 5 or Cat 6 cable. if you can.
I was going to ask a similar question, of what OP's DBS setup was looking like. If it's setup to go out to the outside world, then I can see something like this happening.
Ping and using http are different things. You can't ping over http, it is a different communication protocol. Doing the ping without http is the right way here.
As it turns out, the problem ended up being a problem with my router's DNS. It looks like my router looks externally if I provide it anything in the format of .. When it couldn't resolve it anywhere else, it returned with a dummy stub IP rather than looking internally. Sadly, because I use the circle service for parental controls, it locks out a lot of the settings and there's not a whole lot I can do to correct it.
Oddly, I can ping the Pi from my desktop using hammerpi and it returns with the correct IP, but my laptop won't. Not sure how exactly that works since the DNS is the same, but I'm not overly concerned.
I moved the Pi to a wired connection to correct the inconsistency. It's not worth it to me to force it to 2.4GHz because I live in a location that's so oversaturated with 2.4GHz traffic that it's almost unusable and I can't get it any closer to the router to make 5GHz work better.
What kind of OS are you running on the computer you use to access OctoPrint ?
If you're on Linux, you can add the IP and the hammerpi.local hostname to the /etc/hosts file.
On Windows, there is an equivalent file located at C:\Windows\System32\drivers\etc\hosts, where C: is the drive upon which Windows is installed. It follows roughly the same format as the Linux one.
If you're on Mac OS, there should be the same file, although I'm not familiar with it. A Google search return /private/etc/hosts
Of course, this will only work if the Pi's IP stays the same. You'll need Administrative rights to edit those files, and a reboot after editing them, or at least a session close... This doesn't solve the root of the problem, but at least you'll be accessing your Pi with a hostname instead of an IP address...
As it turns out, I can reach the Pi by host name from every machine in my house simply by dropping .local with the exception of my laptop.
That’s my work laptop though and it’s possible some of the security management software is impacting that. I definitely don’t have the ability to alter the hosts file on that computer.
I’ve got the router set with a DHCP reservation for the Pi. So, I can ensure the IP is consistent.
Sorry for my late and hopefully useful contribution, terminating the name with .local tells the client to use the Multicast DNS responder, previously known as Bonjour instead of your DNS on the router.
This bypasses conventional DNS lookup and throws a multicast name lookup - aka autodiscovery and its how an Airprint printer is found by your iPhone/iPad, which is hardly surprising as a software engineer at Apple developed the original. Have a read of this How .local works . The chances are your work laptop is pushing mDNS .local lookups up your VPN tunnel [mine does the same], so don't use .local as part of your network DNS name.
I should have added that the Raspberry Pi OS, like all incarnations of Debian out of the box isn't configured to use DNS properly, the file /etc/nsswitch.conf has this line:
hosts: files mdns4_minimal [NOTFOUND=return] dns
This must always be changed to
hosts: files dns mdns4_minimal [NOTFOUND=return]
Otherwise DNS is never used, only multicast DNS, aks Avahi, Bonjour, or its original name, Rendezvous.
I change this on every Pi OS instance and use dnsmasq on another Pi dedicated to DNS and DHCP.