Annoying switch to AP mode

[Pasha1402]

I'm facing the following problem: RPI Zero W in WiFi client mode, all works great, however in case of accidental failure to connect to WiFi or get address from DHCP - whole thing switches to AP mode permanently (effect: some script deletes wpa_supplicant.conf and activates hostapd. Reboot obviously leaves RPI in AP mode as it was.

WiFi connection can be restored by manually connecting to RPI and activating WiFi via PRI config page. Python script creates wpa_supplicant and changes config to WiFi mode.

However I failed to find script which auto-reconfigure RPI to AP mode on DHCP failure. Where/what it is? I'd rather disable it to get normal WiFi connection after simple rebooting RPI, not reconfiguring it.

[uaktags]

Same issue for me, the thing just keeps going back into host mode on reboot of the pi

[uaktags]

@Pasha1402
You think this may be it?
etc/init.d/S45IpDNSupd.sh:20: rm -f /etc/wpa_supplicant.conf

[Pasha1402]

@uaktags
No, it is not. This is wpa config, in fact it is generated by .py script when you enter credentials and hit "enable wifi". Upon network failure this file being deleted, in addition to some permission changes to enable AP settings. I was able to find what has changed, but not what does that change... unfortunately my Linux knowledge mostly focused on servers which plugged with permanent cable

[uaktags]

So that init script actually has the fallback you're talking about though. When DHCP fails, Dazen has a bash script in there which deletes the conf file, and resets itself back into AP mode.

the py scripts are only the front end stuff for Raspberry.php, the actually check for dhcp happens in these init.d files.

[Pasha1402]

Sorry, misread your message. Now looking at it and it seems, you are right.

Think right approach would be to to replace it with dummy init.d script that does nothing to avoid potential damage to some other parts of "ecosystem". But maybe simple removal will do the job as well

[Pasha1402]

funny, same script checks if anyone removed Paul's copyright disclaimer from index and if so applies "kill switch" :)

[Pasha1402]

i did the replacement of the line:
if [ "$ipadd" == "" ]; then
with
if [ "$ipadd" == "43" ]; then

thanks for the hint!

[uaktags]

Of course! Glad to help

[uaktags]

Hmm, still getting a strange isntance of it decided to go back to host mode even though wpa is still set.

[Pasha1402]

Have you blocked both sections with [ "$ipadd" == "" ] ? There are two

[uaktags]

Yep, did both, and now it doesn't seem to wanna connect to the AP at all. Probably going to need to hook 'er up to a monitor. Somethings' buggin. Verified dnsmasq, wpa_suppliant, and network/interfaces are all setup correct. Really weird.

[Pasha1402]

it is. mine boot up and connected without issues, so modification itself doesn't bring any damage. on the other hand I experience wifi issues quite rarely. now thinking how would I reproduce issue to check

[uaktags]

I think I got it now, I ended up commenting out all of that BS from that init script that deals with the networkcontroller python. If I need to update the wifi password/ssid I'll do that manually, F using the scripts. the NetworkController py has way too many things of doing removals of files just by default rather than having conditions to check. It may be worthwhile to update cleanly. Too bad they didn't think to use version control for the actual python and bash files, and instead just give us a bunch of version control on the Readme file -_-. So weird of a decision.

[Pasha1402]

Congrats. Might worth making a branch, but doesn't seem using RPI is anyhow popular as ESP32 is way cheaper. I only use RPI as I have few own scripts for keyboard emulation, e.g. remotely switching PS4 off via web call

[uaktags]

Yea, I'm surprised it doesn't have much love but you're not lying on how much gouging is going on with Pi prices. I may have to just cave in and pickup a ESP32 and see how those projects are going.