Raspberry Pi 3A+ WiFi issue

[MW0MWZ]

Just adding in some answers here...

2x wpa_supplicant - its not an issue - you can ignore that (I think - I may live to eat these words, but so far I think its correct).
Seeing the wpa_supplicant for the AP mode - will not make any impact while the interface is not up.

OK at the moment I believe that the issue with the WiFi may have beeb improved with some changes to Raspbian, but the majority of the problem was that the initial random entropy was not available and *everything* that depends on randomness could have been impacted *now fixed in RC7*.

That combined with the recent work to improve the country setup for WiFi (fixing some issues with 5Ghz WiFi) should make for a better experience all around.

Early testing on my Pi 3A+ suggests that AP mode now works like it is supposed to more often than not, WiFi generally works well with one key exception.
If you boot the Pi, and it starts AP mode, and you connect to that to setup the WiFi - and you just reboot it when done, for me that results in broken WiFi quite repeatably

If I do the same thing, use the AP to setup the WiFi and then shut down the Pi, pull the power and power it back up - it seems to work reliably.
With the *very* short amount of testing I have done so far this all seems to be a decent improvement, I'd like to debug the issue on reboot, but that one might be very hard to find!

[DB6BD]

Hi Andy,

Thanks for letting us know you're working on it.

Kind regards,
Dennis

[ea7gwc]

Thank you very much Andy, as soon as I try it, I comment the results

[KE0FHS]

FYI, yesterday evening I updated two hotspots with which I had been having trouble connecting to WiFi on startup, one 3A+ and one 4B. Both have been starting up and connecting to WiFi flawlessly since the update to 4.1.0-RC7. Thank you!

(Actually, I updated the 4B from RC6 to RC7, and I flashed a new RC7 image on the 3A+. I'll be doing more testing with other configurations later today.)

[KE0FHS]

I'm noticing only one minor issue: when I'm first configuring my wireless network for the RC7 image and choose my country code, US, then scan for network, the country code appears to get set back to JP. If I select US again, and then select my network, enter my PSK, and click Save (and connect), it appears to get set back to JP again. But I think it's actually being set, because if I go to another page, like the Admin page, and then return to the Configuration page, it's correctly set to US. Also, when I power off, then back on, it's also correctly set to US.

[MW0MWZ]

I'm noticing only one minor issue: when I'm first configuring my wireless network for the RC7 image and choose my country code, US, then scan for network, the country code appears to get set back to JP. If I select US again, and then select my network, enter my PSK, and click Save (and connect), it appears to get set back to JP again. But I think it's actually being set, because if I go to another page, like the Admin page, and then return to the Configuration page, it's correctly set to US. Also, when I power off, then back on, it's also correctly set to US.

Yeah I did already know about it, I'll see if I can do something with it, its down to the way the page is refreshed.

[MW0MWZ]

I'm noticing only one minor issue: when I'm first configuring my wireless network for the RC7 image and choose my country code, US, then scan for network, the country code appears to get set back to JP. If I select US again, and then select my network, enter my PSK, and click Save (and connect), it appears to get set back to JP again. But I think it's actually being set, because if I go to another page, like the Admin page, and then return to the Configuration page, it's correctly set to US. Also, when I power off, then back on, it's also correctly set to US.

Yeah I did already know about it, I'll see if I can do something with it, its down to the way the page is refreshed.

OK try that, you may still get the slightest flash of the old setting as the page reloads, but it should now reload cleanly and show you the updated setting.

[kc7ngc]

OK at the moment I believe that the issue with the WiFi may have beeb improved with some changes to Raspbian, but the majority of the problem was that the initial random entropy was not available and *everything* that depends on randomness could have been impacted *now fixed in RC7*.

There is a reason you decided to go with the systemd-random-seed.service route for artificially creating entropy on headless systems vs installing the rng-tools package to allow the raspberrypi to just use its built in hardware PRNG?

sudo apt-get install rng-tools
then
sudo systemctl disable haveged

That way random is filled at boot by hardware PRNG and not slower software algorithm.

Installing the rngd service which actually allow the kernel to talk to the hardware PRNG which tends to fix all entropy problems on headless PI's. Using systemd-random-seed can slow boot time as doesn't always generator entropy very quickly. But once rngd comes up you almost instantly get high entropy from the hardware PRNG. (cat /proc/sys/kernel/random/entropy_avail)

Usually rng-tools is the go to to fix entropy issues on the rPIs.

------Just an addition
Systemd-random-seed is generally not a secure method of increasing entropy on systems that routinely have their images/disks cloned to other systems. As on system will low entropy potential you can unintentionally sync all the devices software PRNG as they all start with the same seed material from disk and in the absence of other entropy march forward with software PRNG's that are now in sync.

[ea7gwc]

Right now, when you get home, until the third start you have not connected to the wifi.
The transition from RC6 to RC7 has been from the SSH.
I'm going to record a clean image of RC7, although I guess
it will be the same.

Greetings.

[kc7ngc]

So if this does turn out to be entropy starvation for the wpa supplicant. It would makes sense. I couldn't figure out why pistar image would sometimes not work on a A+ on boot but a fresh stock rasbian buster image would work every time.

rng-tools and the hardware RNG are enabled by default in the stock buster build. But they aren't present in the 4.1 RC builds of Pi-star which is also buster. Would also explain why my A+ stopped malfunctioning awhile ago on pi-star as I had install rng-tools to fix problem where nginx didn't want to work on boot with a TLS certificate. Didn't think it might be related to my wifi issues going away.

So I guess this is a question for Andy. Was the 4.1 RC candidate based on a fresh buster image or was it an upgrade from stretch to buster?

Looking at the /etc/apt/trusted.gpg file it would appear that the 4.1 RC was upgraded from jessie->stretch->buster. Which would explain the absence of the rng-tools in the install as well as some other differences I had noticed between the pi-star 4.1 RC's and regular rasbian buster. If you upgrade from stretch to buster it maintains the same core legacy service configs and doesn't install or configure the newer services such as rpg-tools and some other items that would be present in a fresh image. As doing so would break legacy services that existed prior to the upgrade.