Wifi Setup still flaky with i20250822 and i20251109

[ceejayemm]

As noted in #1965 and #1987, the tried and trusted method of setting up a wifi connection via a 'WiFi' file in the '/BOOT' partition is still flaky in this release. If setup in this way the wifi starts but almost immediately it is shutdown. The only way I have found to configure wifi is manually through the web pages but even this sometimes takes several attempts for it to 'stick'.

The issue, which I documented in #1965 (reply in thread), is with the startup.sh file around lines 140/142

Chris

[ceejayemm]

Any progress please ?

Thanks

Chris

[ceejayemm]

@rern
Is there any solution to this issue or should i just ignore it ?

Thanks

Chris

[ceejayemm]

@rern
This is still an issue with i20251109

Chris

[ceejayemm]

@rern
I am glad to see you back supporting rAudio, I hope you are OK.

Can this issue be fixed ? It is still an issue with i20251109 / 20260111 (and latest updates up to 09:00 GMT Jan 14th) as detailed in the first post of this thread and in the previous posts identified there.

Thanks

Chris

[Alien8ions]

Hi Chris

Not really helping a lot, but I can at least confirm you're not the only one having wifi connection problems

To get the wifi up initially I had to disable local browser to start wifi-menu from cli, now wifi is connected (only automatically on wlan0) only if I disable onboard wifi after setting everything else in boot/config.txt
The networks page won't even open if wlan0 is not connected in time, in my side of the universe it appears to take longer than 30s ...
Since the whole wifi thing hinges on the very existence of $dirshm/wlan0, which gets removed if not connected (in time, at first boot)... Modprobing wifi drivers on the fly is a bit problematic if you're only installing/booting the first time around...

One trick I have used to remediate is add an extra script that replaces that wlan0 file at the end of boot so at least the networks page displays

A8

[ceejayemm]

Thanks, at least I now know I am not going crazy :-) Hopefully Rern will come up with a fix soon.

Chrs

[ceejayemm]

@rern
I have been following your changes to the Update branch. I can tell you that as of 0845 GMT today the changes you have made work successfully for an external USB WiFi adaptor but NOT if I try to use only the internal WiFi of the Pi3A when I still have the original problem.

I have also discovered a small typo whilst checking out the original problem in: /srv/http/bash/status.sh

Line 174 needs to change from:

(( $pos > 0 )) && song=$(( pos - 1 )) || song=0 # mpd song : start at 0

to

(( pos > 0 )) && song=$(( pos - 1 )) || song=0 # mpd song : start at 0

Thanks, nearly there.

Chris

[ceejayemm]

@rern
You must be getting close to another release. Is there any chance that getting rAudio to use on the onboard wlan port can be solved for this release ? As noted above wifi now works when using an external usb wifi device but NOT on the onboard wifi.

This is preventing me from updating 3 x RPi3A+ devices, which are using an old rAudio version but only have the onboard wifi available, to the latest release.

Thanks

Chris

[rern]

I've just tried reboot/power off on my 3B+ a dozen times. Half of which by disconnecting power supply instead of from menu.
No issues connecting Wi-Fi.
Is there wlan0 in ls /sys/class/net? It should connect properly if there is one.

[hjfisch]

A friend of mine has RPI 4 with rAudio working , but only with Lan . It says WLan connection failed . Could it be that special characters in the WIFI-Password are not allowed , because in my Network it is working ?

[Alien8ions]

If I may chip in..

Are the rpi3's in a metal case, rather far from router, behind walls/ceilings perhaps ? Or a lot of iot devices around ? Or lots of neighbors who insist on using the same wifi channels ?
I have noticed it can take more than 30 seconds for wifi scan and subsequent network DHCP negotiate steps.
If not complete in time, the wifi drivers are removed.

As a trial try increasing sec=30 to sec=60 or more in /bash/startup.sh to see if that is the culprit
I did improve things a bit for me

HTH
Alien8

[ceejayemm]

@rern

The problem isn't with the wifi connection surviving a reboot but with setting it up in the first place. On the 3A+ I have historicaly used a 'wifi' file in /boot. Using this method, I can see see the file being actioned by /srv/http/bash/startup.sh (around line numbers 135 - 138, these have changed in recent releases) and the connection IS made for a few seconds but then the logic kills the onboard wifi connection and disables the setting so that it no longer available in subsequent boots.

@Alien8ions - the RPi3A+ is not in a metal case, is around 1.5m from the router and has worked perfectly with previous releases. I believe it a logic issue which is causing the problem as previously detailed.

[rern]

Please post the output of ip -br link .

(Looking for lines started with e but not end0)

[mcisysdev]

Just an idea...

Quote: " the connection IS made for a few seconds but then the logic kills the onboard wifi "

I regulary observe this error on new Linux installions if the WLAN country is not set.
It's the router that refuses to make the connection, not the device. The device only kills the service, when no connection was established.
In the 'wifi' file, I don't see a [country code] parameter and I wonder how this is handled.
When using Raspberry Pi Imager to flash Raspberry Pi OS, I can preset SSID, password, security and country.
May be I'm wrong and things are less restricted in the rest of the world.

[kan-ibal]

I'm not sure when this happened but now systemd-networkd is enabled and run. It used to be dhcpd+netctl for network support and wlan connection in rAudio (and still is) and looks superfluous. Maybe there is some interference.
I have installed latest rAudio image and with systemd-networkd disabled everything still works.

[ceejayemm]

@rern

As requested:

Booted using USB Ethernet conector and with System / Onboard / WiFi enabled:

rAudio-test:~  #  ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
wlan1            DOWN           d8:44:89:91:f5:d1 <BROADCAST,MULTICAST> 
enu1u4           UP             00:50:b6:24:ea:d7 <BROADCAST,MULTICAST,UP,LOWER_UP> 
wlan0            UP             b8:27:eb:59:9e:cc <BROADCAST,MULTICAST,UP,LOWER_UP>

After reboot, with a new '/boot/wifi' file in place. The USB adapter was reconnected after boot to be able to access the system:

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
enu1u4           UP             00:50:b6:24:ea:d7 <BROADCAST,MULTICAST,UP,LOWER_UP> 
wlan1            DOWN           d8:44:89:91:f5:d1 <BROADCAST,MULTICAST> 

The attached snippet file (wlan0_setup.log, attached below) is the relevant output from a 'journalctl -b' command during the reboot above and shows wlan0 initially being identified and configured, dropped and the onboard wifi connection being disabled.

Chris

wlan0_setup.log

[rern]

Conditions to disable onboard WLAN:

• An ethernet exists and online / connected

landevice=$( ip -br link | awk '/^e/ {print $1}' }
ifconfig $landevice | grep inet # output: a line > disable

• There are more than 1 WLAN device

rfkill | grep -c wlan # output: more than 1 > disable

Please try:

• sed -i -E '/wlanOnboard|rmmod/ s/^/#/' /srv/http/bash/startup.sh (Make onboard always enabled)
• Power off
• Remove USB WLAN and ethernet dongles
• New /boot/wifi
• Power on
• Post the output of:

ip -br link
ifconfig
rfkill

[ceejayemm]

@rern

As requested, after carrying out the reboot sequence noted above, I can confirm that System / On-board Devices / Wi-Fi IS enabled and the wifi information is now shown in Networks / Wi-Fi

# iw dev
phy#0
	Interface wlan0
		ifindex 2
		wdev 0x1
		addr b8:27:eb:59:9e:cc
		type managed
		channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
		txpower 31.00 dBm

# iwconfig wlan0
wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

rAudio-test:~  #  ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
wlan0            DOWN           b8:27:eb:59:9e:cc <BROADCAST,MULTICAST>

rAudio-test:~  #  ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16  bytes 2537 (2.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 2537 (2.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rAudio-test:~  #  rfkill
ID TYPE DEVICE      SOFT      HARD
 0 wlan phy0   unblocked unblocked

Interestingly, during the boot process, there is a wait for 1m 30s for:

A start job is running for /sys/subsystem/net/devices/wlan1

but this times out as this path does NOT exist. There is a similar request on shutdown for a reboot 'Expecting device WLAN1' but this appears to do nothing. Note in both cases this specifies wlan1 NOT wlan0

Chris

[ceejayemm]

@rern
Updated to 20260212-2 today, still not able to connect to wifi via onboard wifi adapter, however, this info from the previous post:

Interestingly, during the boot process, there is a wait for 1m 30s for:

A start job is running for /sys/subsystem/net/devices/wlan1

Got me thinking and a bit of Google searching led me to:

https://bbs.archlinux.org/viewtopic.php?id=166607

and from this

grep -ir wlan1 /etc/systemd/*
/etc/systemd/system/netctl@CMHomeNET.service.d/profile.conf:BindsTo=sys-subsystem-net-devices-wlan1.device
/etc/systemd/system/netctl@CMHomeNET.service.d/profile.conf:After=sys-subsystem-net-devices-wlan1.device

then,

netctl disable CMHomeNET

removed the wlan1 network 'profile' (?), and following a new /boot/wifi file and a reboot - seems to have solved the problem. The RPi 3A+ seems to now be working as I would expect. I might just wait a little before marking this as solved - just in case :-)

Chris

[ceejayemm]

Spoke too soon.

Having had success with my test rig above, I moved on to one of my lesser used RPi3A+ "production" systems. I flashed a new SD card with i20251109 and booted using a USB ethernet adaptor to ensure I could get a connection. I applied the latest update release 202602122, created a new wifi file in /boot, removed the USB ethernet adaptor and rebooted. On reboot I could not access the wifi connection and further investigation showed that I had the same problem as at the start of this thread. Not Good!

I then applied the same 'fix' as in the previous post:

netctl disable CMHomeNET

which told me it was removing:

netctl disable CMHomeNET
removed '/etc/systemd/system/multi-user.target.wants/netctl@CMHomeNET.service'
removed '/etc/systemd/system/netctl@CMHomeNET.service.d/profile.conf'
removed directory '/etc/systemd/system/netctl@CMHomeNET.service.d'

I then created another new wifi file in /boot, with no other changes to anything else, and rebooted. This time the system came back up WITH the onboard wifi enabled and working. Checking the system it appears that the files removed above have been recreated:

rAudio-1:~  #  ls -la  '/etc/systemd/system/multi-user.target.wants/netctl@CMHomeNET.service'
lrwxrwxrwx 1 root root 39 Feb 14 09:49 /etc/systemd/system/multi-user.target.wants/netctl@CMHomeNET.service -> /usr/lib/systemd/system/netctl@.service
rAudio-1:~  #  ls -la  '/etc/systemd/system/netctl@CMHomeNET.service.d/profile.conf'
-rw-r--r-- 1 root root 99 Feb 14 09:49 /etc/systemd/system/netctl@CMHomeNET.service.d/profile.conf
rAudio-1:~  #  

I cannot begin to understand why this has the effect it does but I can live with it until somebody better than me works out what is happening and why.

Chris

[R101G]

@ceejayemm

Is the /etc/netctl file being created correctly?

Also, grasping at straws, do you have the same SSID for both frequency bands? If so, does turning off the 5GHz band at the router make any difference?

[ceejayemm]

@R101G
Thanks for your suggestions.

As far as I can tell the /etc/netctl/CMHomeNET file is being created correctly. It is a copy of the settings in my '/boot/wifi' file.

I use Google Wifi (and have done for a long time) so turning off the 5GHz band isn't an option as there is no way to do this in the Google Wifi setup.

Thnaks

Chris

[rern]

Hi Chris,

• A Wi-Fi profile is specific to a certain interface/device.
• Your initial boot with a USB Wi-Fi dongle and /boot/wifi created a profile with Interface=wlan1.
• On-board Wi-Fi is wlan0.
• Simply removing the dongle did not change Interface=wlan1 to Interface=wlan0.
• Do not use the dongles, both ethernet and Wi-Fi, in the first place.
• On-board Wi-Fi should be fine in most situation. Otherwise, it won't be reliable enough to use normally.

[ceejayemm]

@rern
I normally rely entirely on the onboard wifi adaptor for the RPi3A+, I only used the external usb wifi and ethernet adaptors to be able to check the installation, I now have a monitor and keyboard attached so I check what is happening. In the case of the USB Wifi connector (wlan1) this, as you noted, is not removed under certain circumstances and caused me the issues documented.

My current issue is that I still cannot initially get a 'normal' connection via the onboard wifi adaptor, which I have been doing for years via a /boot/wifi file, as the current rAudio logic disconnects it as already documented. The only way I can get a working installation on the RPi3A+ (and also I suspect the RPi Zero W2, but not yet tested this yet) is:

Flash a new SD card with i20251109 including a new /boot/wifi file, which does allow a local wifi connection to be used
Update to the latest Update branch release, currently 202602122 (which on reboot removes the onboard wifi connection)
Don't reboot at this point
Configure rAudio
Turn off Access Point
Create a new /boot/wifi file on SD card, as this initial boot process has deleted the original
Now reboot (onboard wifi adaptor is disabled by this process)

Once system is back up again
Use your script above to ensure the onboard wifi adaptor is permanently turned on (sed -i -E '/wlanOnboard|rmmod/ s/^/#/' /srv/http/bash/startup.sh)
Clear wifi profile, with netctl disable CMHomeNET
Reboot

Now the system reboots correctly WITH the onboard wifi adaptor configured AND working and I can use the system as I would expect.

The issue seems to lay with the current logic which tries determines if an onboard wifi connection is being used and if not (incorrectly in my case) disconnects and disables this device. I do wonder if the confusion is caused by the fact that the RPi3A+ (and the Zero W2) does NOT have an onboard ethernet connector where all the other RPi models do have an onboard ethernet connector ?

As noted above I now have a monitor and keyboard attached so NO OTHER wifi/ethernet connection are currently in use.

Chris

[ceejayemm]

@rern
I don't know what you have done but the new image release i20260216 seems to have resolved ALL the problems identified above. I flashed a new SD card and from the get go the onboard wireless device was picked up and enabled and survives a reboot. I did noit need any of the above workarounds, rAudion seems to be back to its old self (well may be not quite but that will be the subject of a new separate thread).

Thanks very much!

Chris