Hey @OutsourcedGuru - remember me?
Went ahead and plugged into ethernet. Haven't tested yet - but will and see if this resolves. I was curious though - will having ethernet plugged in override the wifi module, or should I trigger this off? If so - how would I go about that? Connecting (putty/browser ui) should all be the same correct?
Hey OutsourcedGuru,
Thank you. So I did as you suggested; plugged my pi to a keyboard & monitor and disconnected the ethernet cable.
Ran ifconfig and got the RUNNING flag for wlan0 and saw the 10.10.10.139 ip address. Could not reach that address through my machine via PUTTY.
Ran routegot the same results as before minus the ethernet info.
Ran ping 10.10.10.254 and nothing else "happened". I tried typing commands but nothing happens. See pic.
@MaplePrints Run a route command and you can confirm that the metric for the eth0 is lower than that of wlan0. This should in most cases translate into "yeah, it will go that route instead of using the wi-fi".
Behind-the-scenes, the Raspi should advertise its hostname on two different devices and your workstation should see the metric and make the right choice.
If you connect with ssh or PuTTY and use the hostname "octopi.local" then this should work out fine in most cases. If you use the IP address, just make sure that you use the correct one of the two.
@salamero Now we're getting somewhere. That's pretty strong evidence that something's wrong with your router's setup on the wi-fi side of things.
What's bothering me is that I've searched for "admin.lan" but it's turning up nothing on the Internet. I worry that this represents the public-facing IP address on your router so this would be an incorrect setting for your wi-fi route.
So, yes. I'm on a guest network I created because my 2.4 Ghz ssid has a space a "+" and a "." in the name, which seemed to be an issue with my pi. I didn't change the name because I have a gazillion smart home devices on that network that I would have to re-set to that new name. I'll do it if I have to but is there a way i can either A) get my pi to "see" that name or B) can I get my pi to connect to my 5Ghz network, which doesn't have the stupid characters issue?I wasn't able to before. Thanks
You can get your Raspberry Pi 3B to connect to your 5Ghz wi-fi zone if you kill it with a spork and replace it with a Raspberry Pi 3B+.
It might be worth trying the trick to pretend that your wi-fi zone is hidden; that might work:
Hello everyone,
so I was using OctoPi with no problems at all for about 3 months. Now I moved to another house and I'm not able to get my OctoPi connect to wifi. I updated SSID and pswd in wpa-supplicants with Notepad++, but without any success. So I tried to go back to my old house with old SSID and pswd and it worked, then I tried to rename my wifi to same SSID and pswd as it was, and it is working, but I can't be using this wifi setup. Can someone please point me to what am I missing?
Using OctoPrint 1.3.10 on OctoPi 0.15.1
EDIT: I have no fancy characters in my new wifi setup, only first capital letter, and some numbers
Thanks in advance.
Is your new wi-fi zone hidden? If it is, then it might behave as you've described. You would need to add scan_ssid=1 to that network paragraph if it's a hidden zone.
If not, then try again.
sudo /boot/octopi-wpa-supplicant.txtCreate two paragraphs for the network section, one with the old and one with the new. Try to keep the new SSID and password simple like lowercase letters, numbers and that's it (no spaces).
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US
network={
# Old house
ssid="SSID"
psk="password"
key_mgmt=WPA-PSK
}
network={
# New house
ssid="SSID"
psk="password"
key_mgmt=WPA-PSK
}
Then change your wi-fi router's zone/password to what you want it to be (just lowercase letters and numbers without spaces to be on the safe side).
Well, I tried adding scan_ssid, but nothing changed. So then I used the old wifi setup, tried to open wpa supplicant, but with no luck (it wrote about 10 rows with unexpected errors), so I entered raspi-config, where I used Network settings to connect to a wifi, and now it works. I might have wrote the old wifi setup here when I was first setting my Pi, so it was kinda "hardcoded" I would say.
Now everything works (only web page is loading slowly than before - might it be the result of adding scan_ssid?), so thank You for your insight into my problem!
I notice some people with Wifi problems run a network cable but I have the same issue with cable. Octoprint starts to load and then disappears of the network and cant be accessed.
Is there a topic to solve this issue please?
@Andy_Taylor You could try reading through this troubleshooting guide. If you're trying to reach your octopi.local using a Windows-based workstation, then you might also read this.
You could attach a local keyboard/monitor/mouse to the Raspberry Pi and run a command like ifconfig and route to see what's going on with the Ethernet and wi-fi adapters in it. If you share the outputs of those with us here, we might be able to advise better.
version OctoPrint 1.3.10 running on OctoPi 0.14.0
I have this exact issue. whoops i thought i was replying to the first post.
restating the issue7:, Wifi does not auto reconnect when signal is lost. The issue in my case is that my router keeps getting dos'd to the point that it is non responsive (asus blue cave ac-2600) so I started setting it to reboot at 4am every day.
Prior to this, until the router became non responsive (due to ddos) once or twice a week and everything (tablet, roku, thermostat, ect) quit working the pi would stay connected all the time. the router is just over 1m away so signal is quite high.
the problem i have is just that it does not attempt to reconnect. is there a command to add or a newer version that does auto connect? I do the updates when they come but I have had this running for quite a long time. so the raspian version looks out of date. the pi is working so well that i'd rather not screw with success if nothing fixes the reconnect.
in case your next question is why ddos, i have a port exposed for remote access to my security system and that port gets pounded thousands of times a day. My old asus ac1900 didn't have a problem with all the probes but the new asus does and i am waiting for a firmware that fixes the issue.
chris
There is no quick fix for a DDOS other than stopping the behavior that got you into this mess in the first place. Prevent the DDOS and the problem goes away since your router will then be able to keep its connections.
yet again i end up replying in the wrong place...
responding specifically to this post. It is a "normal" amount of traffic. with all of the invalid attempts blocked by the asus router's 2 way intrusion protection. it detects the exploit attempt and drops it.
I have had a security system since 2014, and the access attempts and port scans have not markedly increased in that time. The router I have uses a different chipset than the normal asus so this one gets patched slower. and it is in fact only this firmware that really seems to have had the problem.
and I just checked and viola there is an update ready for the firmware so i will install and see what that brings. I did upgrade the pi to octopi 0.16 and with the backup and restore it was really painless. it survived a reconnect already so perhaps i will no longer have the problem with the nightly router reboot.
edit it just survived another reconnect with the firmware upgrade. maybe octopi 0.16 solves the reconnect issues.
here is my reply to your other thread
not exactly. The automated pings and port scanning has always been there, and the asus protection package included with this router sheds all of the connect attempts. it is just that for this asus router there is a bug that causes it to go non-responsive after a several days of this. And while on trips it was causing me to lose connection to my alarm system and my thermostat. as well as losing the ability to remote into my computers.
if you only knew how many thousands of these pings occur to every ip in the world you would not be shocked at how many real exposed vulnerabilities are exploited in this world
Dude, I'm the "Chicken Little" of the Internet, always warning people how much scripting and hacking attempts go on.
What gets a trickle of scripting to turn into an avalanche of scripting is a positive result in one of their logs. You gave them something tasty to chew on, they posted your specifics somewhere on the Dark Web on a list, that list gets side-copied everywhere and now they've all shared this information. Instead of one random drive-by shooting, you're now the victim of DDOS.
The volume hasn't changed in 5 years, this specific router has a buffer overflow in the previous firmware, not sure if it has been fixed or not with the new one I just installed. You are mistaken about the ddos tho, the router is shedding all of the login attempts. Pings are already dropped. So nothing but the normal. The router can even handle the logins it doesn't fail open it fails closed. It didn't do this on the original firmware, but did on the last update. And it might now be fixed. As far as my octopi I just use it to watch my printer not run it. The two are not even in contact. Just a pi usb cam watching the printer print.
And really this hijack of the thread doesn't give me any answers on my reconnect issue. So unless you've got something to add on that point, let's let this be enough on internet security please.
The OctoPi latest image includes the Nov 2018 Raspbian, to the best of my knowledge. If you have a spare microSD, you might install that and see if it behaves better. If it doesn't, you could return to your original.
while i was reading this thread last night I saw 1st that there was a backup and restore utility the latest octoprint, so i backed up, etched the new 0.16 image, restored, and then found a new firmware (from april) for the router so updated that as well. the pi has reconnected so far after 2 router reboots so fingers crossed atm. we'll see if it comes back tomorrow after then next reboot. If it does i'll start to play with the router and stop the auto reboot.