The Mac is 192.168.0.32 phone is 192.168.0.20 and PC is 192.168.0.19 At the office right now and havenāt setup PiVPN so I will post the results from netstat In a couple hours.
- Look at the DHCP lease length on your wifi router's settings. This is part of the "ghost in the machine" that you're chasing. If you imagine yourself printing a multi-day job then it's in your interest to push the lease length to something larger than this duration.
- Locally on the PC and the Mac, there's such a thing as an
arpcache. On either Mac/Windows, run anarp -abefore and then after ping'ing that IP address in question for the Raspi.
$ arp -a
? (10.20.30.1) at a4:2b:8c:d2:ab:22 on en0 ifscope [ethernet]
? (10.20.30.150) at 8c:3b:ad:b3:d8:46 on en0 ifscope [ethernet]
? (10.20.30.151) at 8c:3b:ad:b1:e8:ad on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
$ ping octopi.local.
PING octopi.local (10.20.30.250): 56 data bytes
64 bytes from 10.20.30.250: icmp_seq=0 ttl=64 time=22.621 ms
...
^C
$ arp -a
...
? (10.20.30.250) at b8:27:eb:de:a7:c7 on en0 ifscope [ethernet]
...
So, ping'ing a workstation puts it into your arp cache and makes things later easier (it doesn't have to broadcast to find out who-is-who).
Out-of-the-box, either your Mac or an iPhone (you never indicate what kind of phone you have) would have the Bonjour name lookup service. Windows would not. Adding iTunes to your Windows PC would add that as a side effect.
It's possible that the netmask is set incorrectly for the PC/Mac.
You haven't indicated if both PC/Mac are connected via Ethernet cable or by wifi to the router.
I tried to include as much information as possible. Itās easy to miss a few things. I am using an iPhone X and I have iTunes installed on the PC along with bonjour.
All of the devices I have mentioned are connected via WiFi all on the same network. (Pi, PC, Mac, iPhone.
If I push the lease length wonāt I still eventually be disconnected?
Leaving the office now so I will post the results of the commands mentioned above.
I mean, traditionally your router will give the same IP on a lease, so the length doesn't matter. Mine happens to be 10 hours. I've only really saw pain in a coffeeshop where there's enough turnover that you can run out of lease space.
Basically, you'll know if the lease length is to blame if the Pi's IP address changes.
And based on the low IP numbers, are you using static IPs for any of these devices?
I set the lease time to 1 month, I very rarely add a new device so I don't think this will affect me negatively. I did not have any set to a static and the IP never changes but I went ahead and gave the Pi a static IP.
This is the results for the arp -a command from my Mac.
(base) Deriks-Mac-8:~ derik$ arp -a
? (192.168.0.1) at 50:9:59:80:d6:81 on en0 ifscope [ethernet]
? (192.168.0.3) at 50:9:59:80:d6:82 on en0 ifscope [ethernet]
? (192.168.0.9) at 9c:e3:3f:63:af:b0 on en0 ifscope [ethernet]
? (192.168.0.20) at (incomplete) on en0 ifscope [ethernet]
? (192.168.0.24) at b8:e8:56:14:5b:6e on en0 ifscope permanent [ethernet]
? (192.168.0.28) at b8:27:eb:71:aa:57 on en0 ifscope [ethernet]
? (192.168.0.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
(base) Deriks-Mac-8:~ derik$ ping octopi.local
PING octopi.local (192.168.0.28): 56 data bytes
64 bytes from 192.168.0.28: icmp_seq=39 ttl=64 time=100.219 ms
64 bytes from 192.168.0.28: icmp_seq=40 ttl=64 time=30.829 ms
(base) Deriks-Mac-8:~ derik$ arp -a
? (192.168.0.1) at 50:9:59:80:d6:81 on en0 ifscope [ethernet]
? (192.168.0.3) at 50:9:59:80:d6:82 on en0 ifscope [ethernet]
? (192.168.0.9) at 9c:e3:3f:63:af:b0 on en0 ifscope [ethernet]
? (192.168.0.20) at (incomplete) on en0 ifscope [ethernet]
? (192.168.0.24) at b8:e8:56:14:5b:6e on en0 ifscope permanent [ethernet]
? (192.168.0.28) at b8:27:eb:71:aa:57 on en0 ifscope [ethernet]
? (192.168.0.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
This the the results of the netstat -nr command from my Mac.
pi@octopi:~ $ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
That shows it working from Mac to Pi. I'm curious how it looks when that connection isn't working.
BTW the netstat at the bottom must be from your Pi, not your Mac 
The next time i am unable to access I will post the results from that command. Unfortunately the only thing that I have noticed that affects access is time.
Your right I ssh into the pi to see the output on it and pasted from the wrong terminal.
copypaste errors are easy. no big deal.
It looks okay, so I'm hoping running those command (ping, netstat, arp) when you can't connect will point us in the right direction. And yeah, it's annoying when there's no other way to trigger it! Oh well. I'll hop in the time machine and check here later.
Thanks for all the help.
i also have this issue on my mac
Are you still able to login on a mobile device?
yes i can and am able to start a print from my phone
Do you have the OctoPi image or Octoprint on Raspbian?
Not able to connect this morning, here is the arp -a with a ping before and after from the mac.
PING 192.168.0.28 (192.168.0.28): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
--- 192.168.0.28 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
(base) Deriks-Mac-8:~ derik$ arp -a
? (192.168.0.1) at 50:9:59:80:d6:81 on en0 ifscope [ethernet]
? (192.168.0.3) at 50:9:59:80:d6:82 on en0 ifscope [ethernet]
? (192.168.0.9) at 9c:e3:3f:63:af:b0 on en0 ifscope [ethernet]
? (192.168.0.19) at 4c:ef:c0:37:b6:ba on en0 ifscope [ethernet]
? (192.168.0.20) at 0:71:47:80:d0:ab on en0 ifscope [ethernet]
? (192.168.0.21) at 68:ef:43:6d:db:9 on en0 ifscope [ethernet]
? (192.168.0.24) at b8:e8:56:14:5b:6e on en0 ifscope permanent [ethernet]
? (192.168.0.28) at (incomplete) on en0 ifscope [ethernet]
? (192.168.0.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
PING 192.168.0.28 (192.168.0.28): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
--- 192.168.0.28 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
Here is the IPV4 information from netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 106 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 3 328756 lo0
169.254 link#5 UCS 0 0 en0 !
192.168.0 link#5 UCS 7 0 en0 !
192.168.0.1/32 link#5 UCS 1 0 en0 !
192.168.0.1 50:9:59:80:d6:81 UHLWIir 25 16 en0 1197
192.168.0.3 50:9:59:80:d6:82 UHLWIi 1 58 en0 546
192.168.0.9 9c:e3:3f:63:af:b0 UHLWIi 1 50 en0 743
192.168.0.19 4c:ef:c0:37:b6:ba UHLWI 0 64 en0 1151
192.168.0.20 0:71:47:80:d0:ab UHLWI 0 38 en0 1191
192.168.0.21 68:ef:43:6d:db:9 UHLWI 0 10 en0 142
192.168.0.24/32 link#5 UCS 1 0 en0 !
192.168.0.24 b8:e8:56:14:5b:6e UHLWI 0 2 lo0
192.168.0.28 link#5 UHLWI 0 5 en0 !
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 9 en0 !
224.0.0/4 link#5 UmCS 2 0 en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 54 en0
255.255.255.255/32 link#5 UCS 1 0 en0 !
255.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI 0 9 en0 !
You have a lot of cloned nonsense going on in your Mac's routing table. I'd suggest a reboot and then repeat the netstat from earlier.
If would be nice to see the output on your Mac for ifconfig.
It seems like I have the same problem, I am setting up my new printer with new raspbbery in addition to my current one which is working fine. I am experiencing same issues I can connect to the octoprint server from only some devices. Currently working only with my laptop on the same wifi network, but not working with phone on the same network and my pc connected by lan cable. On the reboot everything works fine but just in hour or so this happens.
Hello @draon7!
For the thread you just linked in is quite old and has no solution, I recommend to open a new thread with filling in as most information as possible that are asked for in the template when you open a new "Get Help" thread.
Story: So I got the same problem using a Windows PC to access OctoPrint on a Pi. After a couple of weeks using it almost 24/7 (printing really got me hooked) my PC couldnĀ“t connect to the Webserver of the OctoPi. Strange thing was all other devices (Phone, Surface, Laptop, etc.) could connect without a problem.
Solution: Evetually I tried almost everything to get rid of the problem and got it solved with the netcfg -d command in CMD (run as admin).
The command clears all configurations on the network adapters (so just use if nothing important is configured on the device you are using). Hope it helps 
1 Like
You are not alone! My Windows 10 machine (with all the updates on both the Pi and the computer) randomly does this too. I can still monitor from the iOS app so that's something, but the computer just refuses to see Octopi when it feels like it. I can't even connect via SSH from the computer when this happens. I don't tend to do really long/big prints. So I just let me little job finish then reboot and get back to it.
Yes a reboot fixes it, and no that's not a solution (while actively printing anyway).
So I was having a similar issue: I could connect to Octoprint and the Pi from my main PC, suddenly but not my phone or spare PC after a fresh install of Octopi. My main PC was connected directly to the router via ethernet, and my phone and spare via wireless. While poking around in the router settings to double check IPs, I noticed both the 2.4Ghz band and the 5Ghz were the same SSID, whereas my previous router I could set them separately. I knew from previous experience setting up smart bulbs that my phone and my bulbs had to be on the same band in order to connect. I checked my router logs, and the Pi and my phone both appeared to be connecting to the 5Ghz band, but still wasn't accessible. That's when I noticed I could give each band a separate SSID, which I did by adding a 5 to the 5Ghz SSID and leaving the 2.4ghz as it was. This forced the Pi , spare PC, and my phone to use the 2.4Ghz band. For some reason this seemed to do the trick, and I'm now able to access Octoprint from all 3 devices.