[Announce] Community Firmware for Squeezebox Radio/Touch/Controller and LMS 8

[slartibartfast]

Do you have the option 802.11b disabled checked? A Lot of users find they can't connect with 802.11b disabled. (This option should probably be removed from the CF)

No, I just have the ARP watchdog checked.

[Tony T]

This happened again this morning (red network icon) when I started one of my Radios. This time I went into Networking Settings and selected choose network. It found my WiFi network and after selecting it the Radio connected to WiFi.

Do you have the option 802.11b disabled checked? A Lot of users find they can't connect with 802.11b disabled. (This option should probably be removed from the CF)

[slartibartfast]

Yeah, unfortunately that suggests to me that the reason the ARP watchdog is not fixing the problem (which it attempts to do by restarting the network stack) is that in that condition, even restarting the network stack is not sufficient to fix it. So it requires a complete reboot.

I wish I understood the root cause of these wifi issues but unfortunately I (still) suspect the bugs are in the wifi firmware, where we don’t have access or source code. Meaning we’re left with work-arounds. Sigh.

Managing how and when to do an automatic reboot (and keeping the system from ending up in a reboot loop) is somewhat tricky and not something I want to take on at the moment… Sorry…

This happened again this morning (red network icon) when I started one of my Radios. This time I went into Networking Settings and selected choose network. It found my WiFi network and after selecting it the Radio connected to WiFi.

[slartibartfast]

Yeah, unfortunately that suggests to me that the reason the ARP watchdog is not fixing the problem (which it attempts to do by restarting the network stack) is that in that condition, even restarting the network stack is not sufficient to fix it. So it requires a complete reboot.

I wish I understood the root cause of these wifi issues but unfortunately I (still) suspect the bugs are in the wifi firmware, where we don’t have access or source code. Meaning we’re left with work-arounds. Sigh.

Managing how and when to do an automatic reboot (and keeping the system from ending up in a reboot loop) is somewhat tricky and not something I want to take on at the moment… Sorry…

Never mind. I should know better than to just assume it has connected to WiFi and not check for the white icon.

[dzenc]

Yeah, unfortunately that suggests to me that the reason the ARP watchdog is not fixing the problem (which it attempts to do by restarting the network stack) is that in that condition, even restarting the network stack is not sufficient to fix it. So it requires a complete reboot.

I wish I understood the root cause of these wifi issues but unfortunately I (still) suspect the bugs are in the wifi firmware, where we don’t have access or source code. Meaning we’re left with work-arounds. Sigh.

Managing how and when to do an automatic reboot (and keeping the system from ending up in a reboot loop) is somewhat tricky and not something I want to take on at the moment… Sorry…

[slartibartfast]

Hmm… I need more info. How did you (manually) resolve the issue and get it reconnected to wifi?

I rebooted the Radio again.

[dzenc]

Hmm… I need more info. How did you (manually) resolve the issue and get it reconnected to wifi?

[slartibartfast]

dzenc I have noticed a couple of times that my Radio doesn't connect to WiFi after a reboot. The first time it happened I turned on the ARP watchdog hoping that would force the WiFi to connect. Recently I rebooted a Radio last thing at night and in the morning it was still disconnected from WiFi so I suspect it never connected. Is this something that could be fixed in firmware?

[tjako]

Hi all,

my 2ct's of experience with the firmware.

I run my LMS server in a container (fedora39 image, updates applied and rpm based lms install with it's own dedicated ip so no host tcp stack sharing)
After I got the LMS server running I enabled the community firmware plugin and soon my 4 squeezebox radio's notified me there was an update waiting to be installed.

Installed 3 of them without factory defaulting first.
Installed 1 of them with factory default first.

All seemed to work fine.
After 1 day one of the 3 without a factory default lost connection.

To get it back online I ensured that:
- a factory default was applied
- configured the network again
- it connected again to my LMS server
- the 'arp watchdog' option is checked
- the 'disable 802.11b' option is UN-checked (checking it ensures that the squeezebox stays offline)

Now I have 4 working squeezebox radios again that make use of my local lms server (running in a container)
Even though the squeezeboxes have 802.11b they all connect using 802.11g/wifi3.

Absolutly fantastic that my squeezebox systems now run firmwares that are not older than my kids.

Cheers

[sgmlaw]

I did the above for total of 3 radios.

The first one was located near to the primary router of the ASUS Mesh network. So far it has stayed connected. Very happy!

The second and third radios are located nearer to the mesh node. Unfortunately, they do not stay connected for long (blue or red icons after 1 to 2 hours).

In an AiMesh network, binding these clients to the router should improve connection stability. AiMesh is prone to drop out very old legacy chipsets when it starts juggling clients around. Asus has improved it on their newest routers, but the problem persists.

I have a pre-UE Radio on factory firmware with the LMS 8 patch, and it holds rock solid indefinitely on AiMesh with binding until there is a router reboot (which necessitates a simple Radio reboot).

But I may play with the Community Firmware to see if I can avoid even that need to reboot.

[THXTEX]

...Please enable the ARP watchdog.

Been running with ARP watchdog but I still get the Blue WIFI icon after some days. ARP watchdog makes it more robust but it still looses connection after some days.

[garym]

Okay, here's my experience.
Did the factory reset. Installed community firmware again.
Wifi b disabled option ticked still crashes Wifi connection. No recovery.
I will leave this option unticked and see whether Wifi connection loss issue is gone or improved without it.

Others have reported this as well. The simple answer is to not tick that option. I don’t tick that option and the community firmware solved my Wi-Fi problem so far.

[Tony T]

Okay, here's my experience.
Did the factory reset. Installed community firmware again.
Wifi b disabled option ticked still crashes Wifi connection. No recovery.
I will leave this option unticked and see whether Wifi connection loss issue is gone or improved without it.

if you want to give this a try, do a factory reset again, but install the Factory Firmware, and then comment out line #29 in /etc/init.d/wlan. https://forums.slimdevices.com/forum...ct#post1642115

[Randyak]

Okay, here's my experience.
Did the factory reset. Installed community firmware again.
Wifi b disabled option ticked still crashes Wifi connection. No recovery.
I will leave this option unticked and see whether Wifi connection loss issue is gone or improved without it.

[Randyak]

It's both radios affected from the malfunction.
To be honest this disable Wifi b function does something else as disabling Wifi b, because Wifi b is already disabled in my router. So it simply shouldn't have no effect.
I cannot imagine why a factory reset would change the behavior of that tweak.
But maybe I will do a factory reset for one of my radios where I don't have so much settings to restore after the factory reset.
Let's see what happens.