search

fluidd-core / FluiddPI

FluiddPi - A Pi image with Klipper, Moonraker, Fluidd and Web Camera support pre-installed.
https://docs.fluidd.xyz
GNU General Public License v3.0
299 stars 58 forks source link

FluiddPi cannot connect to wifi #38

Open LuigiBrito opened 2 years ago

LuigiBrito commented 2 years ago

Used the raspberrypi imager and set the SSID and PW correctly.

I checked the wpa_supplicant files in /etc/wpasupplicant/ and in /boot/fluiddpi-wpa-supplicant.txt and both are showing the correct ssid and a hexadecimal pw

On boot, literally nothing happens. I'm waiting on my unifi to pickup even an attempt but nein. Nothing.

LuigiBrito commented 2 years ago

if I connect to it manually and do a sudo wpa_supplicant -c <conf file> -i wlan 0 it works. But the device it self doesn't seem to do this on its own on reboot

TheFanatr commented 2 years ago

Same problem for me, except I couldn't even get SSH.

rodrigo2019 commented 2 years ago

same for me, I got this problem with the V1.17 image, I have another fluidd running with the V1.16.2 image and it's fine

ressu commented 1 year ago

Assuming that this is the same case that we were troubleshooting recently then the issue should be a race condition with mounting boot volume. For some reason systemd finds a cyclic dependency somewhere and removes some local-fs dependencies and that messes up the order of how services come up. Not having the wpa configuration present means that dhcpcd never starts wpa supplicant.

So with that long explanation, the workaround is rather simple. Creating an override for dhcpcd systemd unit with the following contents forces the service to wait for boot.mount

[Unit]
After=boot.mount

Easiest way to create the override in the correct location is to use systemctl edit dhcpcd.service. The actual file location is /etc/systemd/system/dhcpcd.service.d/override.conf

That all being said, we were unable to find the cause for the circular dependency.

Drkmttr82 commented 1 year ago

Assuming that this is the same case that we were troubleshooting recently then the issue should be a race condition with mounting boot volume. For some reason systemd finds a cyclic dependency somewhere and removes some local-fs dependencies and that messes up the order of how services come up. Not having the wpa configuration present means that dhcpcd never starts wpa supplicant.

So with that long explanation, the workaround is rather simple. Creating an override for dhcpcd systemd unit with the following contents forces the service to wait for boot.mount

[Unit]
After=boot.mount

Easiest way to create the override in the correct location is to use systemctl edit dhcpcd.service. The actual file location is /etc/systemd/system/dhcpcd.service.d/override.conf

That all being said, we were unable to find the cause for the circular dependency.

Is there a reason why I would be denied when trying to use this workaround? I've gotten to ssh into my pi and I can log in. But the web service doesn't start. Checked the supplicant file and all that is good. But when trying this command I get access denied. Not sure how I'm not the SU but it's frustrating.