Any manually-edited wpa_supplicant.conf kills everything but AutoAP

[ki5sr]

This past week a couple of friends wanted help getting their Pi-Zero-W+MMDVM-HAT style hotspots up and running. This is something I've done many times so I was horrified when I couldn't get their hostpots to join my office network at any point. No matter what I tried, it seemed they were deaf to any WiFi network. It seemed like I might have corrupted SD cards every time.

Worse, when I began trying to make network tests on existing working hotspots, they went down, too. At the end of a two hour session, I had four completely inoperable hotspots.

I took them home to a different network. I bit the bullet and reformatted all the SD cards, and started rebuilding each from scratch. On the fourth or fifth build, and noting various behaviors, I discovered: when a manually edited wpa_supplicant.conf was introduced into the /etc/wpa_supplicant/ directory on any of these spots, the spots failed to read them. So we stopped using any manual editing or preconfigured wpa_supplicant.conf files in the boot directory.

(Bafflingly, this was true of wpa_supplicant.conf files generated by the "WiFi Builder" utility on the "Pi-Star Tools" section of the PiStar.UK website. They would break the hotspot, too.)

Once we started doing all Wireless configuration through the Pi-Star Configuration menu, waiting for scans to complete, entering passwords, etc., everything worked perfectly and as expected. As soon as a new network entry was added to the machine-built wpa_supplicant.conf file, it would stop connecting and jump into AutoAP mode with whatever name the node had been given. If you'd done it carefully, then going into the Configuration screen and using the WiFi configuration tools there to delete the manually-added entries would bring the things back to life.

So now all four hotspots are up and running. Two are MMDVM_HS_DUAL_HAT spots, one is an MMDVM_HS_DUAL_HAT spot with a OLED display, and one is a MMDVM_HS_HAT with an OLED display.

All of the hotspots in these experiments and builds were made using the Pi-Star_RPi_V3.4.16_10-Aug-2018.zip image burned to the SD cards with Etcher or its rebranded successor.

I can say with reasonable confidence what the problem is, how to work around it, and when it's occurring. What I'm at a loss for is to tell you why these differences are happening.

I'm reasonably sure we can rule out the file editors, as this is a problem whether one uses vim on external machines or the vi editor on the raspberry Pi that is brought up on a ssh connection.

Just passing along what we've learned here at KI5SR and friends.

[KE0FHS]

I'm not sure I follow everything in your post, but if you manually create a wpa_supplicant.conf file, it should be copied into to the boot partition of the microSD card. Then, when Pi-Star is booted up, the file gets an automatic process moves it into the /etc/wpa_supplicant/ folder. If you want to make changes to it, you can do that via the Configuration page of the Pi-Star Dashboard, in the Wireless Configuration section. You also can edit the file via WiFi Config in Pi-Star's Expert Editor.

[ki5sr]

I'm not sure I follow everything in your post, but if you manually create a wpa_supplicant.conf file, it should be copied into to the boot partition of the microSD card. Then, when Pi-Star is booted up, the file gets an automatic process moves it into the /etc/wpa_supplicant/ folder. If you want to make changes to it, you can do that via the Configuration page of the Pi-Star Dashboard, in the Wireless Configuration section. You also can edit the file via WiFi Config in Pi-Star's Expert Editor.

Yes—that's the usual way. On the current build, the wpa_supplicant.conf file does get copied to the /etc/wpa_supplicant/wpa_supplicant.conf position.

And then the wireless will completely fail to work. Eventually (if AutoAP is enabled) it will boot up as the host for a wireless network named after it's node name. This is true even with a wpa_supplicant.conf file generated by the Pi-Star home page utility with no subsequent modifications.

That's the part that we're not understanding.

It's also generally allowed that one may edit the /etc/wpa_supplicant/wpa_supplicant.conf file in a Raspberry Pi (and in BSD and most Debian derivatives) to edit the wireless configuration.* But if you do that, it will fail to work, and (if AutoAP is enabled in the Pi-Star configuration page, it will boot up offering a network named after its own node.

I know that first post seems TL;DR-worthy, but it was a meticulous testing and debugging process. It's worth going back and following along for anyone troubleshooting the problem.

*See also 'man wpa_supplicant.conf(5)' in the appropriate places.

[KE0FHS]

Well, perhaps something else is going on with your setup or configuration.

I'm took a ZUMspot hotspot (firmware v1.4.12) on a Raspberry Pi Zero W, and reflashed its microSD card with a fresh download from the Pi-Star website (Pi-Star_RPi_V3.4.16_10-Aug-2018) using Etcher, and ejected the microSD card.

Then I used Pi-Star Tools WiFi Builder to create a fresh wpa_supplicant.conf file (using dummy credentials ... I would never enter my real PSK on an open website), downloaded that to my Windows 10 laptop, edited it with Notepad++ to add my main wireless network, copied that file to the re-inserted microSD card, which I then used to successfully boot the hotspot.

Once Pi-Star was up and running, I did all the normal configuration, including adding a second wireless network (my mobile network) using the Wireless Configuration section on the Pi-Star Configuration page, and then rebooted successfully.

After that, I opened Termius and connected to the Pi-Star hotspot, ran a Pi-Star Update to bring me up to 20181111. (I actually had to run the update twice, as the first time performed a fairly major Jessie update and didn't update the dashboard itself, but the second time successfully updated the dashboard to 20181111.)

Finally, I opened Termius and connected to the Pi-Star hotspot again, switched to the root user, enter rw mode, and used nano to edit the main file itself: nano /etc/wpa_supplicant/wpa_supplicant.conf. I changed the order of the two wireless networks so that my mobile network was first, wrote the changes, and then rebooted successfully again.

Finally, I went into the Expert Editor > WiFi, removed the mobile network, changed my main network entry to the first network (id_str="0"; priority=100), applied changes, and then rebooted successfully again.

I never used Auto AP during this entire time (though that is what I usually use). Everything worked just fine. My wireless connectivity never failed.

[ki5sr]

I know there are some inconsistencies depending on which versions, images, and update stages things are at.

I have one hotspot at home that was never affected by this. When I edit its wpa_supplicant.conf, it works just fine. More to the point, the wpa_supplicate.conf file remains owned by root and with a root group id no matter how it gets changed. It remains that way when it's edited with vi or with the Pi-Star dashboard tools. Oh! And the permissions on all the files are invariably 766.

On these three I've just rebuilt with the image currently distributed by the website, any edits coming from the dashboard tools have a uid and gid of "www-data" and the permissions are always 644. Any edits of the existing file using vi end up with a wpa_supplicant.conf owned by uid root and gid root.
Again, the permissions are 644.

I'm not in a place where I can accomplish it right now, but it will be very telling to do the build on the current release image and get a "deaf" hotspot that will only do AutoAP. Then see if that can be awakened into normal function with a chance in owner, group, or permissions.