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

[dzenc]

Many thanks. Of course it built just fine !

There's not too much I can do, but I have made a review of the SW62 patches that were being carried. (We don't have the source, but we do have the patches !)

My comments in the attached PDF.

I guess we would still be wanting atheros_shorter_scan_list_cache_timeout.patch, but that could be tested. I don't know about scan_many_ssids.patch, I suspect it may have been dealt with in SW83. There are others that I would wish to understand.

Of course, this is all moot if dzenc is defeated !


[ATTACH]n1639853[/ATTACH]

Thank you! This is actually super helpful. My comments:

1. The two patches I pulled in, attempting to fix the kernel crash, are: BMI_READ_MEM_FAILURE.PATCH and CHANGE-AR6K-SEMAPHORE-TYPE.PATCH. I suspect we want both of them.

2. Re: AR6KSDK.BUILD_SW.62.BABY.PATCH

• I ended up adding "-DDEBUG" back, so we should probably delete that edit (which removes "-DDEBUG") from the 83 patch.

The rest I'll need to review.

[dzenc]

Upon reflection, I think ralphy 's fix for "AR6000 updating target stats" is probably the better one, since it eliminates the spamming even when DEBUG is enabled (and having DEBUG enabled is super helpful).

With respect to the ATHEROS_SHORTER_SCAN_LIST_CACHE_TIMEOUT.PATCH, I believe that affects how long an "inactive" node stays in the cache, not how long the scan takes. I don't know what the actual impact of that is.

[ralphy]

BMI_read_mem_failure.patch is for the eeprom tool, which is not being built in the 1.1 recipe.
I couldn't get any of the tools to build in 83 out of the box and didn't want to spend the time before the driver was proven working, so the firmware is using the same tools as the binary driver.
Sorry I missed the semaphore type patch, that's likely the cause for the kernel crash.

[dzenc]

Ahh… makes sense. All good!

[dzenc]

My current build has the new driver + some patches + old wifi firmware, and I've been running it on all of my Radios (with the exception of the one that I've held back on the old driver for comparison).

So far, with it, there have been no crashes, no asserts, no sluggish UI, and no disconnects that I've observed. Whew.

The one gotcha with this combo is that the driver is failing to report wifi signal strength, which was initially causing some UI glitches, but I've since worked around that by having it always report "good" signal strength. I was worried this would possibly prevent the system from detecting/reporting loss of wifi signal, but I tried turning off my access point and the Radios properly showed a red wifi icon, as expected. When I turned it back on they all reconnected (and turned white), also as expected.

So it seems that the only side effect of this is that you won't see one bar, two bars, three bars, etc. telling you the signal strength of your wifi. You will just see all or nothing if it's connected or not.

In the future, I hope to fix this bug, but for now, this will have to be good enough.

It may be too early to hand this out, but since it's been working well here, and seems to have resolved the known issues, I'm going to be adventurous. If you are also feeling adventurous, please give it a try.

Files are here (Already renamed to custom.baby.*) - https://github.com/dzenc/SqueezeBuil...ain/testv1.zip

For installation, please refer to Ralphy's instructions for pushing it the Radio, found below: (basically, unzip this zip into the LMS cache/updates directory and trigger an update from your Radio; I've found that I didn't need to restart LMS or restart the Radio, but I DID need to go into the Radio and manually start the update using Settings/Advanced/Software Update) I look forward to any feedback.

https://forums.slimdevices.com/forum/user-forums/3rd-party-software/110192-announce-community-firmware-for-squeezebox-radio-touch-controller-and-lms-8?p=1639569#post1639569

[mrw]

My current build has the new driver + some patches + old wifi firmware, and I've been running it on all of my Radios (with the exception of the one that I've held back on the old driver for comparison).

So far, with it, there have been no crashes, no asserts, no sluggish UI, and no disconnects that I've observed. Whew.

The one gotcha with this combo is that the driver is failing to report wifi signal strength, which was initially causing some UI glitches, but I've since worked around that by having it always report "good" signal strength. I was worried this would possibly prevent the system from detecting/reporting loss of wifi signal, but I tried turning off my access point and the Radios properly showed a red wifi icon, as expected. When I turned it back on they all reconnected (and turned white), also as expected.

That is encouraging.

One point I would make: it will be essential to test thoroughly with the UI. We had some unexpected issues when updating wpa_supplicant which took some sorting out, because of UI incompatibility. And these were not immediately apparent.

It would be very good to figure out the signal strength reporting issue. If not resolved it will cause endless confusion with users. Perhaps a difference in old versus new firmware reporting data structure. In which case there may be other differences that have yet to surface.



I had a further look at AR6KSDK.BUILD_SW.62.BABY.PATCH:

A) Should we not be setting ATH_OS_SUB_TYPE := linux_2_6 in the 83 patch ?

B) The patch to os/linux/wireless_ext.c which makes static and increases the size of a holding buffer should do no harm, and might possibly do some good.

The reason why Logitech made the patch is not stated. It has been carried forward since SW18. Now, I found an older version of wireless_ext.c (link below) which certainly suffered from the potential for buffer overflow, and it is possibly that which motivated the patch. That seems to have been fixed in SW83. For the keen, compare the procedure encode_ie. You'll notice that SW83 contains an additional bufsize -= 2 which deals with the overflow that I spotted.

The subject matter is associated with assembling and reporting properties of scanned BSSID's. It is ultimately invoked by ar6000_ioctl_giwscan.

I suspect that the source of the underlying data may be the firmware itself. Can we guarantee that a buffer size of 256 chars is alwys enough even in unexpected circumstances ? I don't know.

https://github.com/mirko/openwrt-x-b...#LL33C1-L33C10

C) The patch to wlan/src/wlan_node.c has also been carried forward since SW18. I don't know why it was felt necessary.

[mrw]

With respect to the ATHEROS_SHORTER_SCAN_LIST_CACHE_TIMEOUT.PATCH, I believe that affects how long an "inactive" node stays in the cache, not how long the scan takes. I don't know what the actual impact of that is.

I would wish to check that out before removing the patch. We would not want to build up an "endless list" of stale/out of date entries in the UI, it is not helpful. Perhaps that was what was motivating fm. Notice that, in an Android environment, the number is set to 30000.

[dzenc]

That is encouraging.

One point I would make: it will be essential to test thoroughly with the UI. We had some unexpected issues when updating wpa_supplicant which took some sorting out, because of UI incompatibility. And these were not immediately apparent.

It would be very good to figure out the signal strength reporting issue. If not resolved it will cause endless confusion with users. Perhaps a difference in old versus new firmware reporting data structure. In which case there may be other differences that have yet to surface.

Agreed. I wanted to focus on testing connectivity before digging into the depths of why signal strength wasn't working. Wouldn't make much sense to focus on debugging signal strength only to find out that the connectivity issues or crashes were still there.

I'd also be happy to get some assistance with the signal strength issue, if you want to spend some time looking at it...

I had a further look at AR6KSDK.BUILD_SW.62.BABY.PATCH:

A) Should we not be setting ATH_OS_SUB_TYPE := linux_2_6 in the 83 patch ?

I don't think it's needed. From host/Makefile:

# ATH_OS_SUB_TYPE - on linux, this must be "linux_2_4" for 2.4 kernels or left blank for 2.6 kernels.

Thanks for the additional analysis. I'll have to review the rest...

[mrw]

I'd also be happy to get some assistance with the signal strength issue, if you want to spend some time looking at it...

More than happy to, if this new driver/old firmware is the way to go. But I think you still have plenty on your plate before reaching that point. Including a determination of whether this all solves the basic issue being addressed !

I have never encountered it, so I can’t actually test the point. (Unless something might be done with hostapd and a supportive usb adapter).

Anyway, I’m away for a few days, so I shall leave you in peace.

[dzenc]

I would wish to check that out before removing the patch. We would not want to build up an "endless list" of stale/out of date entries in the UI, it is not helpful. Perhaps that was what was motivating fm. Notice that, in an Android environment, the number is set to 30000.

I suppose it depends on how mobile your Radio is. On android, it makes sense to expire SSIDs quickly since it is reasonably likely that your device (phone) is constantly moving, and old ssids have gone out of range. For a stationary device, this is much less problematic because ssids don’t come and go that often when you’re sitting still.

Our Radio, being both AC and battery powered, probably sits somewhere in between. For most, I imagine it’s mostly stationary. But occasionally it moves. (Is anyone carrying it in their pocket like a cell phone?

[staresy]

It may be too early to hand this out, but since it's been working well here, and seems to have resolved the known issues, I'm going to be adventurous. If you are also feeling adventurous, please give it a try.

I've been running this dev version overnight (>12 hours). It's been successfully streaming FLAC files all night, no hiccups, radio still streaming this morning and fully responsive.

This compares to the previous dev version which would lose connection within an hour or so and the radio would become sluggish.

So, so far very promising, I'll leave it running.

One to note is that to my knowledge the radio under test isn't in a WIFI-6 environment, so I'm not testing resilience to that, just robustness/stability of the firmware. I'll test on one of my WIFI-6 affected radios when I get a chance (they are at another location, so I'll update one of those devices next time I visit).

[dzenc]

Awesome. Thanks for testing.

[staresy]

Another observation probably worth mentioning...

During testing of the dev firmware's I noticed that my test radio would struggle even on standard community FW (ie non dev r16916 FW) to stream FLAC for extended periods. It wouldn't lose WIFI connection, but would halt playback after a while.

I had never noticed this before because I don't often use this radio for extended periods and, if I do, it's usually streaming 128kbps internet radio (not 650kbps FLAC).

The radio is in a location with poor (low level) WIFI, so I assume when streaming higher bit rates, the poor WIFI signal occasionally allows the playback buffer to run dry, halting playback.

Anyway, the latest dev firmware seems to eliminate this issue, so it appears to handle poor (low level) WIFI environments better.

[dzenc]

It would be very good to figure out the signal strength reporting issue. If not resolved it will cause endless confusion with users. Perhaps a difference in old versus new firmware reporting data structure. In which case there may be other differences that have yet to surface.

And... Your diagnosis was spot-on! Good job! Signal strength bug found and fixed. Fortunately for me, rather than including the driver's header file, the squeezebox app source code had a local copy of the stats structure. Between that and an older version of the driver SDK which I also located, I was able to see the differences in structure and account for them in the driver.

In parallel, on all my devices in use I am continuing to test the same build I previously posted - https://forums.slimdevices.com/forum...55#post1639955 - and it continues to run flawlessly. At this point, I would definitely encourage others to try it and provide feedback. Thanks!

[dzenc]

ralphy - planning ahead for when we've collected enough beta feedback, how do you think we should coordinate checking these changes in? Happy to discuss in PM if that's easier.