Raspberry Pi 3A+ WiFi issue

[kc7ngc]

I expressed my thoughts on that a while ago, Andy replied that he did it on purpose to scan for every possible network.

viewtopic.php?f=3&t=1915&hilit=country% ... t=10#p8879

I find it very annoying that it constantly forces JP no matter what setting you put in there. I just no longer use the wifi configuration area of the dashboard at all, it seems that whenever you click save, it completely erases all of your prior network settings and sets the country to JP for you.

I also have backups of my wpa_supplicant just incase the dashboard decides to nuke my custom settings for me again.

Guess the main problem is that setting it JP doesn't make it hit all the channels. It DOES for 2.4ghz but really screws up 5ghz. For example makes it impossible for radio to associated with 5ghz channel numbers 149,151,153,155,157,159,161,165 in the U.S. because 5735->5835 is not allowed in japan. Also kills channel 138 (5650–5730) and channel 142(5690–5730) because in Japan it only goes up to 5710 not 5730.

In Europe it the country=JP settings kills 5ghz Channels 32, 34, 68,96,138,142, and 149 through 173.

Country code 00 (Default when not set) is what is supposed to be used to look for all channels on all bands. As having a 00 crda code makes radio passively listen for access point beacons on all frequencies, then when it associates with something it should take it's country code from the AP it associates with.

Setting correct country code speeds up associations, because it allows radio to actively check for access points and not wait for a beacon. But having the wrong code will keep radio from associating at all on many channels.

Should really be setting correct country code in /etc/default/crda and not in WPA supplicant as it effects modules when they load not just when supplicant starts.

[MW0MWZ]

I expressed my thoughts on that a while ago, Andy replied that he did it on purpose to scan for every possible network.

viewtopic.php?f=3&t=1915&hilit=country% ... t=10#p8879

I find it very annoying that it constantly forces JP no matter what setting you put in there. I just no longer use the wifi configuration area of the dashboard at all, it seems that whenever you click save, it completely erases all of your prior network settings and sets the country to JP for you.

I also have backups of my wpa_supplicant just incase the dashboard decides to nuke my custom settings for me again.

Guess the main problem is that setting it JP doesn't make it hit all the channels. It DOES for 2.4ghz but really screws up 5ghz. For example makes it impossible for radio to associated with 5ghz channel numbers 149,151,153,155,157,159,161,165 in the U.S. because 5735->5835 is not allowed in japan. Also kills channel 138 (5650–5730) and channel 142(5690–5730) because in Japan it only goes up to 5710 not 5730.

In Europe it the country=JP settings kills 5ghz Channels 32, 34, 68,96,138,142, and 149 through 173.

Country code 00 (Default when not set) is what is supposed to be used to look for all channels on all bands. As having a 00 crda code makes radio passively listen for access point beacons on all frequencies, then when it associates with something it should take it's country code from the AP it associates with.

Setting correct country code speeds up associations, because it allows radio to actively check for access points and not wait for a beacon. But having the wrong code will keep radio from associating at all on many channels.

Should really be setting correct country code in /etc/default/crda and not in WPA supplicant as it effects modules when they load not just when supplicant starts.

The original idea was sane (back in the good old days of 2.4GHz only) but you are quite right, this setting was causing 5GHz users some pain...
wpa_supplicant.conf on Rasbian has required the country code for some time, I never looked too hard at why, but it does have to be set, if its not set, the WiFi was non-functional on some boards, its why we started setting it - and since at the time Pi boards only had 2.4HGz wifi, JP *was* the right choice.

I have now set the WiFi config to display the current country code, and to give you the option to set it correctly too.

See how that works out for you.

[ea7gwc]

OK, thanks Andy.
I have updated pi-star and see that new option in the Wi-Fi configuration.

But what is strange to me is that because with the same regional settings in PI3 B + and PI3 A + (same micro SD) there are only problems
in PI3 A +.

I'm going to try these days to see what happens.

Thank you.

[ea7gwc]

I'm sorry but the problem continues.
Now I needed three ignitions to
The rp3 A + starts working with Wi-Fi.
Once it starts well, it works perfectly and
The wifi is stable.

[kc7ngc]

I'm sorry but the problem continues.
Now I needed three ignitions to
The rp3 A + starts working with Wi-Fi.
Once it starts well, it works perfectly and
The wifi is stable.

As I am running a version of the Pi-Star image that is customized quite a bit as it also runs my RTL-SDR (SDR Radio receiver to APRS) I often don't notice the differences between the current distro and my own custom beast. I just stuck an SDcard in a different pi to test the wifi country code fixes an noticed something.
This might be another squirrel and might not be the cause of the issue at hand but:

When you ssh into your pi-star and run:
ps aux | fgrep wpa_supp

How many wpa_supplicant processes do you see running?

Are you seeing two different wpa_supplicant processes referencing the wpa_supplicant.conf file?

[kc7ngc]

So I think there might be a race condition going on at boot. As on the 4.1 Pi-star images there are conflicting wpa_supplicants starting up. Saw this when I went back to a new burn of the stock 4.1 RC and went to start updating it.

When you aren't connected to an AP, and Pistar is running in AP mode you see:
root 332 0.1 0.6 11228 3216 ? Ss 16:29 0:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
root 853 0.1 0.6 11228 3164 ? Ss 16:31 0:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0_ap -Dnl80211,wext
root 1209 1.6 0.9 10616 4464 ? Ss 16:34 0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

The third process shouldn't be there. It's there because things are starting up with ifup and systemd. The first one is bound to wlan0 the second to wlan0_ap and the third is bound to the dbus. The first two are being started /etc/networks/if-up.d/wpasupplicant

When I am pistar is connected to an AP see two entries:
root 329 0.0 0.6 11228 3344 ? Ss 16:39 0:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
root 1023 0.7 0.9 10616 4448 ? Ss 16:40 0:00 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

First one is what expect, which is the pistar connected to my access point and we don't see a wlan0_ap entry because pi-star isn't running as an access point. But we do see the same /sbin/wpa_supplicant process running. Which shouldn't be there. That version is getting spun up by systemd.

It's possible that there is a race condition here, as above you see the wpa_supplicant we want (329) is has lower process id than the one we don't want (1023). But is theoretically possible that there is a race condition here where the one we don't want comes up first and claims the wifi adapter and doesn't connect to ap properly. (Just a guess as haven't been able to duplicate it here)

So I ran:

Code: Select all

rpi-rw
sudo systemctl stop wpa_supplicant
sudo systemctl disable wpa_supplicant
rpi-ro

Which tells systemd to shutdown its version of the supplicant and to disable autostarting at next boot. Which leaves me with:
root 329 0.0 0.6 11228 3284 ? Ss 16:39 0:00 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext

Which is what I want. So far everything is working as expected without systemd starting up another wpa_supplicant. Still connects to my AP when booted, comes up in AP mode when I don't have an SSID configured. I am not sure systemd bringing up the extra wpa_supplicant is what was causing Pi 3A+ issues or not, but worth a shot I guess.

My hope is that on a 3B+ the ethernet adapter is causing a different wait condition at boot keeping the race between the systemd supplicant and the init supplicants from being an issue. But with a 3A+ without an ethernet adapter the timing makes things an issue. But that is just a guess as I can't current get my 3A+ to misbehave right now. But systemd is pretty new and might explain why this issue started in 4.1. My best guess anyway.

[KE0FHS]

So I think there might be a race condition going on at boot....

I sure appreciate all the work/research you're doing on this issue!

[ea7gwc]

Code: Select all

rpi-rw
sudo systemctl stop wpa_supplicant
sudo systemctl disable wpa_supplicant
rpi-ro

I have already sent it and now I only see one process.
I'm going to try it, to see if the problem continues.
Thank you very much for your work.

[ea7gwc]

After these two days of testing, I am sorry to tell you that the problem continues.
It's a shame but this PI A + is currently going to the drawer.
Also say that I've been testing again
Raspbian Buster with desktop on this PI3 A + and the wifi
It starts and works perfectly.

Regards.

[MW0MWZ]

I have finally gotten my hands on a Pi 3A+ to mess with - and guess what, mine is also giving me issues (this is good actually, there is nothing worse than trying to debug a problem you dont have yourself).

So watch this space, lets see what I can find out.....