28th pdate and pi-star not connect with wifi

[KC1MAC]

(yesterday) Wow what a day, I have been on the phone since 9am with hotspots outages of all flavors. Screen is blank, wont connect to wifi, new wpa files have 2 new lines of code that look like encryption, firmware failures.. All after the update of 28 can anyone shed some light on this --- Thank you
they seem to be able top hard wire but we built new images and they only way to connect is hardwired. 5 different people from 5 different states
and the newly created wpa file is odd?

Any help would be great

[KE0FHS]

and the newly created wpa file is odd?

FYI: After seeing your post, I just took a look at /etc/wpa_supplicant/wpa_supplicant.conf and don't see anything unusual.

This particular hotspot is a LoneStar MMDVM Simplex mounted on a RPi 3A+ running 4.0.0-RC4, 20190628, firmware v1.4.17).

It should be noted that I only update manually. This morning (29th), I noticed that Andy had made quite a few changes, including some to wifi.php:
https://github.com/AndyTaylorTweet/Pi-S ... its/master
so I ran a manual update (two actually; one using the update button in the Pi-Star dashboard, and a second using the sudo pistar-update command via SSH in case there were any OS updates).

Not sure what's different about my setup that I didn't run into the same issue as all the people you're trying to help, but figured this context might help you focus your troubleshooting efforts. I noticed that Andy made seven changes to wifi.php yesterday. I wonder if there's any chance that some people got an update at some mid point? Don't know if that's likely or even possible, but if it is, that could explain why some people have a messed up wpa_supplicant.conf file, while I don't. Perhaps installing a clean wpa_supplicant.conf file and running another update would help?

[KE0FHS]

The only other issue I see with the configuration is that its configured for Japan's wireless standards and that seems weird.

That's normal. JP is the default country code because it has the broadest selection of channels. It's fine to leave that as is, no matter where you are located.

[KE0FHS]

Sure, you're welcome to disagree. But it is the default setting (run the WiFi Builder tool on the Pi-Star website and you'll see that this is true: http://www.pistar.uk/wifi_builder.php), and I've simply shared the reason it is that way. Leaving or changing the default setting will have no impact on the issue being discussed in this topic.

[KC1MAC]

and the newly created wpa file is odd?

FYI: After seeing your post, I just took a look at /etc/wpa_supplicant/wpa_supplicant.conf and don't see anything unusual.

This particular hotspot is a LoneStar MMDVM Simplex mounted on a RPi 3A+ running 4.0.0-RC4, 20190628, firmware v1.4.17).

It should be noted that I only update manually. This morning (29th), I noticed that Andy had made quite a few changes, including some to wifi.php:
https://github.com/AndyTaylorTweet/Pi-S ... its/master
so I ran a manual update (two actually; one using the update button in the Pi-Star dashboard, and a second using the sudo pistar-update command via SSH in case there were any OS updates).

Not sure what's different about my setup that I didn't run into the same issue as all the people you're trying to help, but figured this context might help you focus your troubleshooting efforts. I noticed that Andy made seven changes to wifi.php yesterday. I wonder if there's any chance that some people got an update at some mid point? Don't know if that's likely or even possible, but if it is, that could explain why some people have a messed up wpa_supplicant.conf file, while I don't. Perhaps installing a clean wpa_supplicant.conf file and running another update would help?

Thank you

[KC1MAC]

and the newly created wpa file is odd?

FYI: After seeing your post, I just took a look at /etc/wpa_supplicant/wpa_supplicant.conf and don't see anything unusual.

This particular hotspot is a LoneStar MMDVM Simplex mounted on a RPi 3A+ running 4.0.0-RC4, 20190628, firmware v1.4.17).

It should be noted that I only update manually. This morning (29th), I noticed that Andy had made quite a few changes, including some to wifi.php:
https://github.com/AndyTaylorTweet/Pi-S ... its/master
so I ran a manual update (two actually; one using the update button in the Pi-Star dashboard, and a second using the sudo pistar-update command via SSH in case there were any OS updates).

Not sure what's different about my setup that I didn't run into the same issue as all the people you're trying to help, but figured this context might help you focus your troubleshooting efforts. I noticed that Andy made seven changes to wifi.php yesterday. I wonder if there's any chance that some people got an update at some mid point? Don't know if that's likely or even possible, but if it is, that could explain why some people have a messed up wpa_supplicant.conf file, while I don't. Perhaps installing a clean wpa_supplicant.conf file and running another update would help?

Thank you -- I did not have the same issue either I just got calls from a bucnh of folks whose screens quite working , could not connect, and other after the update..

[KE0FHS]

Thank you -- I did not have the same issue either I just got calls from a bucnh of folks whose screens quite working , could not connect, and other after the update..

Interestingly, after writing the above, I was tinkering with another hotspot (adding a cooling fan) and ran into the issue of my Nextion screen turning blank (white). I tried a bunch of troubleshooting steps. I thought for a time that I might've fried my screen and/or the modem board or RPi. I kept swapping out different components, but nothing revived the screen (I even tried a different screen). Eventually, I installed a fresh 4.0.0-RC4 image, but even that didn't work. Finally, I decided to try one last step before giving up, which was to start over with a fresh 4.0.0-RC3 image, and that worked! I ran a Pi-Star update via the link in the Pi-Star dashboard, then ran a second Pi-Star update via SSH to catch the OS updates that were released since RC3 came out, and finally ran a Pi-Star upgrade to get back to RC4. Since then, everything has been working fine.

Strange stuff, but I'm happy to be back and running. And the fan, a Noctua NF-A4x10 5V, is great. It lowers the temperature of that particular hotspot by nearly 10 F. Life is good!

[MW0MWZ]

That's normal. JP is the default country code because it has the broadest selection of channels. It's fine to leave that as is, no matter where you are located.

Well, I disagree, the country code should match the country you live in. You could use channels that are out of band in the US and cause interference, which as amatuer radio operators we should be well aware of.

I deliberately set the country to JP, so that on scan the Pi will find all networks, at this point its a passive thing waiting for network beacons - so I dont have a problem with it - and once you connect it will only TX on the channel in use.

you can of course argue that out with me, and equally you can set it to your home country to be sure you adhere to the regulations.

[MW0MWZ]

Looks like Andy was trying to hide plain text information in his wpa_supplicant.conf creator, and might of made a mistake.

Not exactly, since I include the plain text also - this is actually a valid thing to do - the WiFi_Builder was incorrectly adding the quotation marks on the HEX version of the SSID - that is what was causing the problem, and has now been fixed up.

So WHY all the obfuscation you might ask - well because iPhones are a pain in the ass is why

Converting the SSID string to hex (thats all it is) and removing the quotes causes WPA supplicant to be able to process the weird / dumb / stupid right quote that apple insists on using in the SSID for iPhone Hotspots.

Similarly, encoding the PSK (in the same way that the wpa_passprase CLI tool does), helps with any unusual characters in the PSK.

As weird as the new look wpa_supplicant.conf files are, they do work (when I don't have quotes in the wrong place).

[KE0FHS]

Not exactly, since I include the plain text also - this is actually a valid thing to do - the WiFi_Builder was incorrectly adding the quotation marks on the HEX version of the SSID - that is what was causing the problem, and has now been fixed up.

So WHY all the obfuscation you might ask - well because iPhones are a pain in the ass is why

Converting the SSID string to hex (thats all it is) and removing the quotes causes WPA supplicant to be able to process the weird / dumb / stupid right quote that apple insists on using in the SSID for iPhone Hotspots.

Similarly, encoding the PSK (in the same way that the wpa_passprase CLI tool does), helps with any unusual characters in the PSK.

As weird as the new look wpa_supplicant.conf files are, they do work (when I don't have quotes in the wrong place).

Andy, what does this mean in terms of creating a wpa_supplicant.conf file and putting it in the root directory prior to boot up? If we create our own wpa_supplicant.conf file with plain text entries, will Pi-Star add the hex conversions as part of the process of moving it to the /etc/wpa_supplicant directory? Or do we have to use the WiFi Builder tool on the Pi-Star website? If the latter, any chance you could add https to the Pi-Star website, or at least to the WiFi Builder tool?