Raspberry Pi 3A+ WiFi issue

Help setting up WiFi
kc7ngc
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: Raspberry Pi 3A+ WiFi issue

Post by kc7ngc »

I think there are multiple issues going on. But never narrowed it down as my stuff is working now but don't know which specific thing I did that fixed my problems. But I know these are two of the bigger things I did.

#1 3A+ and Pi Zero running out of memory
Configuring the locales using dpkg, etc on a 3A+ (or a Pi Zero) will most often run the system out of memory. Causing watchdog to start killing processes which often include killing the SSH daemon and sometimes wifi.
Fixed: I fixed this by adding a swap partition to my images. I didn't want swap on all the time, but there when installing updates etc. So I modified lines in /etc/bash.bashrc to turn swap on when I did rpi-rw and off when I did rpi-ro
In the lines below from the /etc/bash.bashrc file my swap partition is mmcblk0p3 on the sdcard. Depending how you setup your swap this could be different.

Code: Select all

alias rpi-ro='sudo mount -o remount,ro / ; sudo mount -o remount,ro /boot; sudo swapoff /dev/mmcblk0p3'
alias rpi-rw='sudo mount -o remount,rw / ; sudo mount -o remount,rw /boot; sudo swapon /dev/mmcblk0p3'
#2 Country Code kept getting reset to JP
I found that the country code in my wpa_supplicant.conf kept getting changed back to being JP. Finally narrowed it down to the dashboard script: /var/www/dashboard/admin/wifi.php kept overwriting my country code in the wpa_supplicant.conf file everytime I added a new network. Doesn't effect 2.4ghz as 1-11 channels are pretty standard everywhere but makes a big deal for 5ghz connections.
/var/www/dashboard/admin/wifi.php

Code: Select all

 if(isset($_POST['SaveWPAPSKSettings'])) {
                $config = "ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev\nupdate_config=1\nap_scan=1\nfast_reauth=1\ncountry=JP\n\n";
                $networks = $_POST['Networks'];
Can see the "country=JP" at end of the line.

I don't know why the dashboard has JP hardcoded. Maybe thought was it was the most portable across regions? Anyway I changed the JP in the code above to US in my case. Which can get overwritten if update pistar. So I keep an eye on it. If you don't add access points very often then the wifi.php script won't overwrite your current settings. But I travel and take my hotspot on the road, so took me a while to find out that the dashboard was reason why when I came home I have was all of the sudden back to JP.

I apologize to everyone as to me this is a pretty big bug, and meant to file an issue on it over on github awhile ago. But like most things, once I found a workaround, it stopped bugging me, and fell off my radar.

JP gives you:
country JP: DFS-JP
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM
(4910 - 4990 @ 40), (N/A, 23), (N/A)
(5030 - 5090 @ 40), (N/A, 23), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 23), (0 ms), DFS
(59000 - 66000 @ 2160), (N/A, 10), (N/A)

US gives you:
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

Which makes a big difference in 5ghz band.
kc7ngc
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: Raspberry Pi 3A+ WiFi issue

Post by kc7ngc »

KE7FNS wrote: Fri Dec 06, 2019 2:35 am
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.
User avatar
MW0MWZ
Site Admin
Posts: 1505
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: Raspberry Pi 3A+ WiFi issue

Post by MW0MWZ »

kc7ngc wrote: Fri Dec 06, 2019 3:48 am
KE7FNS wrote: Fri Dec 06, 2019 2:35 am
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.
Andy

73 de MW0MWZ
http://pistar.uk
ea7gwc
Posts: 36
Joined: Wed Apr 11, 2018 3:53 pm
Location: Malaga, Spain

Re: Raspberry Pi 3A+ WiFi issue

Post by 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
Posts: 36
Joined: Wed Apr 11, 2018 3:53 pm
Location: Malaga, Spain

Re: Raspberry Pi 3A+ WiFi issue

Post by 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
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: Raspberry Pi 3A+ WiFi issue

Post by kc7ngc »

ea7gwc wrote: Fri Dec 06, 2019 9:17 pm 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
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: Raspberry Pi 3A+ WiFi issue

Post by 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.
User avatar
KE0FHS
Posts: 1122
Joined: Wed Apr 11, 2018 8:40 pm
Location: Colorado, USA
Contact:

Re: Raspberry Pi 3A+ WiFi issue

Post by KE0FHS »

kc7ngc wrote: Sat Dec 07, 2019 1:39 am 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!
73, Toshen, KE0FHS
Playing with Pi-Star (unofficial notes about setting up and using Pi-Star):
https://amateurradionotes.com/pi-star.htm
ea7gwc
Posts: 36
Joined: Wed Apr 11, 2018 3:53 pm
Location: Malaga, Spain

Re: Raspberry Pi 3A+ WiFi issue

Post by ea7gwc »

kc7ngc wrote: Sat Dec 07, 2019 1:39 am

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
Posts: 36
Joined: Wed Apr 11, 2018 3:53 pm
Location: Malaga, Spain

Re: Raspberry Pi 3A+ WiFi issue

Post by 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.
Post Reply