Yes, this really makes sense. After using 0.18.0, it's broken. I'm now using 0.18.x RC2 which works the best.
That's a little strange, because what Charlie was saying is that they are functionally the same. 0.18rc2 became 0.18 stable with no changes.
Just want to let you know this build (RC2) just finally experienced that symptom again - the only difference was... happened on 7th day (assuming that's my duration of DHCP lease as per defined by my router) rather than happening everyday.
Strange enough, if you assign static IP for it, it still needs to be refreshed every time DHCP lease expires?
I've just started having this issue on my Octopi 0.18.0 and Octoprint 1.5.3 install. I've been running this on RPi 4 for about a month with no issue, then starting 2 days ago, I drop the network connection during long prints. When not printing, it appears to stay up and connected just fine. I've left it running for 2 to 3 days without losing connection.
I know this doesn't add much towards a solution, but misery loves company, right?
I'm having the same issue - new build with RPi 4. loses wifi connection mid print, although print continues fine, so a DHCP lease timeout would make sense. I had already assigned a static ip prior to the issue and run just the latest basic Octoprint with no plugins. I have an Asus router that was mentioned earlier in the thread, anyone know the issue with these routers and a fix?
This WMM setting on ASUS routers is what I've seen. Disabling that seems to resolve the issue for another user, although it was with a Pi 3B+. I have seen lots of posts relative to Pi 4 and WiFi connectivity issues, and highly recommend at least connecting and running sudo apt update and sudo apt upgrade via SSH to your pi to ensure that you have the latest stable kernel driver updates.
I have an ASUS router (Zenwifi XT8) with a mesh setup. I had this problem for a little over a week. I spent some time with it over the weekend and think this is either related to DHCP leases or attempts by the mesh node to hand the Pi off to another node. I made these changes and so far, so good.
- Changed device from DHCP to static IP
- Created a static binding to a single node of my mesh network. I don't know if node roaming was an issue, but there router log entries associated with roaming about the time the device dropped.
- Disabled IPv6 on the Pi as it is not enabled on routers and because could I could see some IPv6 activity in the Pi log around the time the device dropped from the network
Yeah, I know not good troubleshooting to change multiple variables at once, but there were really no downsides to the changes and hopefully, I'll never have to revisit this again.
I take back my last post. During a print today, it went offline again. This time I have good logs from the ASUS router.
Mar 2 08:40:45 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind DC:A6:32:C0:09:DB, status: 0, reason: Disassociated due to inactivity (4), rssi:0
So this seems to be telling me that OctoPi is not responding to the router so the IP address is being dropped. I've been using Octoprint for about 6 weeks and this is a new problem that started on or after 2/25. No changes to the ASUS router during this time, so something is different with the way that OctoPi or Octoprint is behaving.
Time for more research...
Thanks I had already updated the latest kernel drivers with sudo apt update and sudo apt upgrade but my issue arose despite doing that. I didn't try any long print prior to doing the updates and as I've just managed to break my sd card 
I'll do a fresh install, see if I get issues with the old drivers and then try the WMM disable - I have an Asus RT-AC88u too.
I did a fresh install with OctoPi 0.18.0, did not run any updates and to date have had no wifi connection issues. This includes 2 >6 hour prints. I'll see how things go but so far so good using a fresh install without running sudo apt udate etc
i also have this problems of intermittend Wlan Failure - so im going to give octopi 18RC2 a try - where do i find that special image? I searched and found links which dont work anymore...
After discovering the problem i also did a fresh install tof 18.0 to get rid of octoscreen packages which i dont use anymore but the problem is still there...
BTW - i just saw that the powersave-fuction of wlan0 is on.
I try to disable that and loook if that fixes the problem...
It may but I think I read another post that said it didn't, but I may be wrong.
All I did was use a new sd card (I broke my original) and freshly install octoprint from the home webpage, edited the wifi settings file as usual and launched it. I didn't install any of the updates options that it gives you when you first log in (and neither did I use the sudo apt update command) and it's been fine since. It occasionally disappears from the web browser (edge) that I'm using (and I'm guessing that this is the point when it would become unresponsive in my original build) but I just put the ip address back in and it's there - no issues at all. At least not since doing it a couple days ago.
Someone stated that 0.18 RC and 0.18 use the same network package.
And to narrowing down the problem, possible scenario:
a) Repeatedly accessing to view webcam activity via OctoPrint app and/or The Spaghetti Detective app increases chance of triggering a network issue
b) Power management being auto/enabled may complicate things
c) DHCP lease
My workaround that works for me (temporarily):
If you absolutely need Pi to work again (ie: still busy printing), just reboot router. Pi will automatically re-establish network with fresh slate.
I enable remote management for my router so I can remotely request it to reboot.
It would be nice if they find the cause and fix the bug.
WiFi auto sleep I think is disabled in current OctoPi nightly releases, but it isn't in 0.18.
That's interesting, it appears that the script might actually place it after the exit 0 in rc.local? Wouldn't that prevent it from applying?
Nevermind, was looking at the wrong commit.
I disabled powersave/autosleep successfully, but still had an issue with the connection dropping mid-print. I was hopeful this would have been the solution, but alas, no luck.
Oh, one more bit of info. This was not a long print, 18 minutes total. Lost connection between 12 and 15 minutes into the print.
Please also share us your Pi, what OS version is it running on?
browser.user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 1500
env.hardware.ram: 1770663936
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.2
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.5.3
printer.firmware: Prusa-Firmware 3.9.2 based on Marlin