OctoPi WiFi/network connection troubleshooting megatopic

And yet, here is the contents of the original /boot/config.txt from an OctoPi-imaged Raspi:

# Using this file to configure your network connection is no longer supported.
#
# Please use octopi-wpa-supplicant.txt instead.

A very long, closed Issue on Guy's repository.

@MaplePrints If you're using Windows on your workstation, perhaps treat this as a name resolution problem and see if this helps.

Note that @DaveedAlvarez said they were on the (by now quite ancient) OctoPi 0.13, which was still using octopi-network.txt. Careful of the version numbers :wink:

1 Like

Yes, I read that part as well . As I said I'm using a very stable version 0.13, which uses the octopi-network.txt., right?

Sure, I'll give that a try and report here. Thanks!

Also -

I am still going to give this a shot when I end up at home today, however I'm not sure this would be the route issue considering I also run a Macbook Pro with OSX that also can't reach - this is getting a "timeout"/"host is down". As well I am able to reach on my windows machine after a reboot.

@MaplePrints Alright then, for the moment ignore the name resolution aspect of this. If it were me, I think I'd put a monitor/keyboard/mouse on the Raspi itself, log in and run an ifconfig to see what's what.

@DaveedAlvarez Not sure which version of Raspbian that was. If it was Jessie then things maybe were different (pre-dating wpa-supplicant possibly).

If you had a second microSD card, you might consider dropping in the shiny-new OctoPi image that just came out to see if that's happier.

Thank you for the reply, I tried the newer version, 0.15. But that one just doesn't connect to anything at all maybe not compatible with an older Raspberry PI?. Anyways, perhasp I mangled the Suplicant file on my first try to edit it, so I will try to burn and brand new version and start from scratch being more careful.
Two questions:
1.-If I get 0.15 up and running how do I transfer the jobs on my Octoprint version on the older card?
2- About the 0.13, how come it seems to ignore whatever I write on the octopi-network.txt file and just go to the old configuration?

Sounds good. I'll update you with those details tonight.

Sorry limited access while I'm at work/Putty is down on it. But I appreciate your help :slight_smile:

#2. I know that the octopi-wpa-supplicant.txt file includes a pragma which basically says "rewrite the main settings upon bootup if you see this here": update_config=1. Not sure if the older octopi-network.txt supported that. If it did and it's missing or set to zero, then it might dutifully ignore any updates to this file...?

#1. Transfers:

  • scp: Since I'm on macOS, I routinely use scp to copy things here and there from my Raspis and workstation.
  • rsync: The command line rsync program is great for pulling entire directories from one computer to another.
  • You could compress everything into a zip file and then pull it over and unzip it when it lands where it needs to be.
  • Not that you have it yet, but the latest versions of OctoPrint come with a nice Backup/Restore bundle plugin
  • If it's useful, I created an upgrade helper if you're handy. In your case, I don't think you should restore using this because you'd then corrupt your changed configuration files and such. The backup portion might be easier than some of the suggestions above. Assuming that you're not a UNIX geek, you might want to go to school on the script itself to see how one might compress/uncompress things.
  • If you have access to a Linux workstation, you could insert the microSD into an adapter and into this workstation. You could then use this to transfer files, say, to that Desktop and over to the other microSD card. The files are in the second partition's /home/pi/.octoprint/uploads folder.
  • Likewise, you could boot your own computer with an Ubuntu Live CD/USB and do this from your own workstation (without installing anything to your hard drive).

Honestly, the Raspberry Pi 3B is an awesome platform for running your printer. You might consider investing in a hardware upgrade. This one has four fast cores and does the job well.


I created a step-by-step guide for installing OctoPi if this is helpful at all.

Edit: Basically disregard all this, apparently I could still connect in putty/the ui I just had to refresh.. But I'm going to wait until I'm not able to and then try to ping my router. I'll update you with results when this duplicates again

Hey @OutsourcedGuru - sorry for the delay here, had a pretty busy end to the week.

So I did run an ifconfig after the UI went down / I couldn't connect to putty as I stated before. Looks like everything is working on the pi itself on the network side. I have a IP, and 0 errors.

Any other ideas? Like I said, I'm unfamiliar with pi so I'm not really too sure where to look next, but willing to provide whatever I can. :slight_smile:

For ifconfig, you want to make sure that wlan0 adapter includes the RUNNING flag as seen below, that it has a bound IPv4 IP address, the netmask is correct for your network on that same line.

Neither RX nor TX errors should be more than, say, 3 packets.

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.20.30.61  netmask 255.255.255.0  broadcast 10.20.30.255
        inet6 fe80::f374:bdc8:ef9f:f16  prefixlen 64  scopeid 0x20<link>
        inet6 2600:8801:9905:b400:60ee:760:4143:b913  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:61:26:01  txqueuelen 1000  (Ethernet)
        RX packets 14476  bytes 5423019 (5.1 MiB)
        RX errors 0  dropped 16  overruns 0  frame 0
        TX packets 13759  bytes 3174035 (3.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If all that is happy from the local Raspi and you can't remote in then go back to treating this like a name resolution problem.

Hey @OutsourcedGuru,

See below ifconfig result (sorry if there's a type-o or two, I had to manually type this since I can't connect to putty):

eth0: flags4099<UP,BROADCAST,MULTICAST> mtu 1500
          ether b8:27:eb:e0:8a:10 txqueuelen 1000 (Ethernet)
          RX packets 0 bytes 0 (0.0 B)
          RX errors 0 dropped 0 overruns 0 frame 0
          TX packets 0 byes 0 (0.0 B)
          
lo: flags=73<UP,LOOPBACK,RUNNING> MTU 65536
           inet 127.0.0.4 netmark 255.0.0.0
           inet6 ::1 prefixlen 128 scopeid 0x10<host>
           loop txqueuelen 1000 (Local Loopback)
           RX packets 610463 bytes 76832841 (73.2 MiB)
           RX errors 0 dropped 0 overruns 0 frame 0
           TX packets 610463 bytes 76832841 (73.2 MiB)
           TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST, RUNNING,MULTICAST> mtu 1500
           inet 192.168.1.175 netmask 255.255.255.0 broadcast 192.168.1.255
           inet6 fe80:2c77:92if:21a5:951c prefixlen 64 scopeid 0x20<link>
           ether b8:27:eb:b5:df:45 txqueuelen 1000 (Ethernet)
           RX packets 995015 bytes 154258171 (147.1 MiB)
           RX errors 0 dropped 171312 overruns 0 frame 0
           TX packets 708215 bytes 124126354 (118.3 MiB)
           TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I also ran a ping to my router, with the result, which is the same result when I ping on my windows machine:
From 192.168.175 icmp_seq1= Destination Host Unreachable

Some additional information:
Remember - when I boot this up I can connect on OSX and Windows, so I'm not sure it is naming. But totally willing to be proven wrong with my lack of experience here.
But this does not disconnect if I connect the pi and leave idle. I left for two days with no result. However - if I start a print it seems to happen within the first 8 hours or so of a continuous print.

I have not tested if this is the case if I do multiple small prints that equal 8 hours or more though.

Looks like you missed a ".1" there.

Again - this was typed not copied :frowning: verified photos - 1 was typed in the command

It's possibly that your router is giving short DHCP leases. If it were me, I think I would read the name resolution link I gave earlier and from that, dedicate an IP address for the Raspi ("Another workaround"). But you'd also need to tell your router to dedicate that IP address.

All this kind of still sounds like it's name resolution. (If after two days the old lease expired, your computers may be confused.)

@OutsourcedGuru -

Following the instructions provided, and this resolved this issue for one night. However, then following night this continued to happen.

As a reminder - I am using both macOSX and windows, the print continues, but the connection via putty, the IP ui in a browser, ping test either way (from the pi to the router or vice versa) are all unsuccessful.

  • You ping'd the Raspi and then suddenly ssh/PuTTY worked. This puts the Raspi's MAC address in your arp cache, btw. It then makes it easier to resolve its IP address in the DNS client.
  • You wait 24 hours and then it doesn't. (Did you try ping'ing again?)

If that's what you're seeing then this looks like short-leasing from your DHCP server. Tell your router to dedicate an IP address to your Raspberry and this problem should go away. Having done so, editing the Windows's machine's HOST file with that entry should take away the pain.

I'd be surprised if that doesn't sort you out.

Hi @OutsourcedGuru,

Point 1 is incorrect. After a restart pinging works no problem, however once this decided to not connect - pinging does not allow ssh/putty to work. No connection is possible until the pi itself is hard-reset. I can try to dedicate an ip though and see if that helps.