BalenaSound Raspberry Pi 4B Suddenly Not Connecting to WiFi.

Hey there! First time Pi project here, so forgive any noobishness. Yesterday I set up my brand-new Pi 4B with BalenaSound following the guide from your blog (https://www.balena.io/blog/turn-your-old-speakers-or-hi-fi-into-bluetooth-receivers-using-only-a-raspberry-pi/) and it worked perfectly for the day. Had my music streaming great via AirPlay for about 5 hours. Then, this morning, I went to use it again and found it wasn’t connecting (four quick green lights on ACT). I’ve been troubleshooting all morning but haven’t found any obvious answers in the forum.

It works if I connect via Ethernet, but I can’t seem to make it re-connect to my WiFi the way it so seamlessly did the first time. What could have changed, and how do I get it to reconnect?

So far I’ve tried:

Reformatting, deleting all existing Balena-Cloud applications, and reflashing via BalenaEtcher (same problem, ethernet only)
Double-checking the credentials in system-connections/resin-wifi - They appear correct
I’ve run nmcli c via ethernet and it looks like the following:

NAME                UUID                                  TYPE      DEVICE      
Wired connection 1  87056728-2d92-3b91-8a84-4c8a80377799  ethernet  eth0 
supervisor0         129f41f8-3b6c-4fec-ac35-053d49016cd6  bridge    supervisor0 
resin-wifi-01       a58e405d-fdc2-3649-9339-5bbaea740c76  wifi      --  

I’m concerned that the DEVICE column is blank on the resin-wifi.

Thanks so much for your help!

Hi Zack,

Great to see you are trying the project!

Here’s my output from nmcli c:

root@debug-device:~# nmcli c
NAME                UUID                                  TYPE      DEVICE      
Wired connection 1  84de4dd8-c3d3-3372-959c-1bfd35afe638  ethernet  eth0        
resin-wifi-01       a58e405d-fdc2-3649-9339-5bbaea740c76  wifi      wlan0       
supervisor0         5c69e56b-c400-438e-854a-a87d63e74f6d  bridge    supervisor0 

You can see mine shows the wlan0 device.

Could you paste the results from the following commands run on the host:

nmcli device status
ip link show

Thanks

Thanks for the response! Here’s what I got from nmcli device status:

DEVICE           TYPE      STATE         CONNECTION         
eth0             ethernet  connected     Wired connection 1 
supervisor0      bridge    connected     supervisor0        
wlan0            wifi      disconnected  --                 
balena0          bridge    unmanaged     --                 
br-1dce75a85fee  bridge    unmanaged     --                 
resin-dns        bridge    unmanaged     --                 
veth6728e03      ethernet  unmanaged     --                 
veth8bf456c      ethernet  unmanaged     --                 
vethbf49d04      ethernet  unmanaged     --                 
lo               loopback  unmanaged     --                 
resin-vpn        tun       unmanaged     -- 

and ip link show gives me:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
    link/ether dc:a6:32:e4:4d:bc brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel qlen 1000
    link/ether ca:31:c9:21:10:77 brd ff:ff:ff:ff:ff:ff
4: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
    link/ether fa:44:b6:ea:1d:fd brd ff:ff:ff:ff:ff:ff
5: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 02:42:06:5f:b5:19 brd ff:ff:ff:ff:ff:ff
6: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 02:42:94:0a:5f:46 brd ff:ff:ff:ff:ff:ff
8: br-1dce75a85fee: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 02:42:d8:c7:5a:e1 brd ff:ff:ff:ff:ff:ff
22: vethbf49d04@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
    link/ether aa:c2:74:d5:47:9c brd ff:ff:ff:ff:ff:ff
28: veth6728e03@if27: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
    link/ether c6:c7:93:be:71:ca brd ff:ff:ff:ff:ff:ff
30: veth8bf456c@if29: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
    link/ether 12:f5:d5:3e:fc:4a brd ff:ff:ff:ff:ff:ff
32: resin-vpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel qlen 100
    link/[65534]

Hi Zack,

Do you have another WiFi SSID you might try connecting to? That would be a way to test to see if the onboard wifi and configurations are working. Also, the RPi 4 should work with 2.4 GHz and 5.0 GHz IEEE 802.11ac wireless networks so you could try connecting to a 2.4 SSID and a separate 5.0 SSID to see if there’s an issue with the band it’s trying to use.

John

Oddly enough, it does work when testing a connection to my phone’s personal hotspot (5GHz).

nmcli device status now:

DEVICE           TYPE      STATE        CONNECTION    
wlan0            wifi      connected    resin-wifi-01 
supervisor0      bridge    connected    supervisor0   
eth0             ethernet  unavailable  --            
balena0          bridge    unmanaged    --            
br-1dce75a85fee  bridge    unmanaged    --            
resin-dns        bridge    unmanaged    --            
veth0e803c4      ethernet  unmanaged    --            
veth2633d80      ethernet  unmanaged    --            
veth362d1c0      ethernet  unmanaged    --            
lo               loopback  unmanaged    --            
resin-vpn        tun       unmanaged    --   

ip link show from that:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq qlen 1000
link/ether dc:a6:32:e4:4d:bc brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel qlen 1000
link/ether dc:a6:32:e4:4d:bd brd ff:ff:ff:ff:ff:ff
4: resin-dns: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue qlen 1000
link/ether c6:54:8c:aa:93:43 brd ff:ff:ff:ff:ff:ff
5: br-1dce75a85fee: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
link/ether 02:42:16:37:45:59 brd ff:ff:ff:ff:ff:ff
6: supervisor0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
link/ether 02:42:2d:28:d2:e6 brd ff:ff:ff:ff:ff:ff
7: balena0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
link/ether 02:42:e6:1c:72:a8 brd ff:ff:ff:ff:ff:ff
9: veth0e803c4@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
link/ether 92:bd:43:c8:04:9a brd ff:ff:ff:ff:ff:ff
11: veth362d1c0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
link/ether a6:ad:17:67:ea:9f brd ff:ff:ff:ff:ff:ff
18: veth2633d80@if17: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-1dce75a85fee 
link/ether fe:d7:9a:e6:f6:57 brd ff:ff:ff:ff:ff:ff
19: resin-vpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel qlen 100
link/[65534]

Oddly, it also seems to work when I try to connect it to my network’s 2.4GHz band. It’s only the 5GHz that isn’t connecting (and it did before). I’m wondering if maybe my router has activated some sort of security against it? Sorry, my networking chops aren’t great.

Dude, IoT networking is hard. No worries!

It could be that your router is broadcasting both 2.4 and 5 on the same SSID and your device is getting “confused” if it tries to hand off from one to the other. If both bands share the same SSID, you might edit your router settings to give each band a unique name (such as mywifi and mywifi-5 and then update your connection profile on your RPi if necessary.

There’s also a way to edit the WiFi configuration file on your RPi to limit wireless to a specific band. This is a little more involved, but guarantees only one band is used. This thread has details.

John

Ha, I appreciate it. Nah, the SSIDs are different, so that shouldn’t be it…

You might do some other poking around in your router to see if there’s something else in there you can change. For example, if the WiFi channel is “noisy,” you could switch to another, or explicitly select a channel instead of using “auto”.

John

Good to know it seems to be network-specific, though still puzzling. It seems to be running great on 2.4 so I’ll call this solved for now. Thanks for your help!

Sure thing! Let us know if you figure out why the network was acting the way it was