Simplified instructions for Squeezebox Radio Wi-Fi fix (wlanpoke)

[rdeckard]

Regarding my previous post, the IO Gear adapter is arriving today.
Anything to look out for when using the Radio's wired Ethernet port?
Does using wired automatically disable WiFi in the Radio?
If not, should it be disabled?
If so, I don't recall seeing an option to disable it in the Radio menu.

[garym]

Regarding my previous post, the IO Gear adapter is arriving today.
Anything to look out for when using the Radio's wired Ethernet port?
Does using wired automatically disable WiFi in the Radio?
If not, should it be disabled?
If so, I don't recall seeing an option to disable it in the Radio menu.

You don't need to disable wifi. But, simply plugging in the ethernet cable doesn't connect the radio to ethernet. You need to go through the setup on the RADIO and select the wired network instead of wifi.

[rdeckard]

You don't need to disable wifi. But, simply plugging in the ethernet cable doesn't connect the radio to ethernet. You need to go through the setup on the RADIO and select the wired network instead of wifi.

Sure, I'm aware of the wired Ethernet setup. I have other wired and wireless Squeezeboxes in my house, all with static IPs, which is what I intend to do with this Radio. I'll report back after I get everything set up. Thanks!


***UPDATE***

Up and running with the IO Gear WiFi bridge. No issues so far.
Was simple to set up, and after editing the interfaces file in the Radio (removed the WiFi entries), I'm back to the same static IP I had when the Radio was on WiFi.
Note for anyone following along that the IO Gear adapter gets unusually hot. Seems this is "normal".
Do the Vonets get toasty too?

[JJZolx]

Sadly, wlanpoke did nothing for my Squeezebox Radio. I moved the Radio to within three feet of my wireless access point. The signal couldn't be any stronger. It still disconnects after a few minutes and stays disconnected.

[rdeckard]

Sadly, new issues have now surfaced with the wired connection.
It will stay up for most of a day, but the last 2 nights, whilst still pingable and seen by LMS, the radio gets into a sluggish/unresponsive state, and requires a reboot.

First thing I noticed when I walked into the room and turned on the light, the radio display remained dark, when it usually would have gone bright from the auto-brightness feature.
After about 10-20s, it did get brighter, but from there, every button press took about 5-10s to actually respond, making the radio unusable, and only a reboot resolved it.

Could it just be that I need to factory restore it after all the troubleshooting/tweaking I've been doing over the past week or so?
If I do that, will I have to deal with reloading the Community firmware again?
Any other suggestions?

[rdeckard]

Sadly, new issues have now surfaced with the wired connection.
It will stay up for most of a day, but the last 2 nights, whilst still pingable and seen by LMS, the radio gets into a sluggish/unresponsive state, and requires a reboot.

First thing I noticed when I walked into the room and turned on the light, the radio display remained dark, when it usually would have gone bright from the auto-brightness feature.
After about 10-20s, it did get brighter, but from there, every button press took about 5-10s to actually respond, making the radio unusable, and only a reboot resolved it.

Could it just be that I need to factory restore it after all the troubleshooting/tweaking I've been doing over the past week or so?
If I do that, will I have to deal with reloading the Community firmware again?
Any other suggestions?

Have now disabled wlan in the radio as per https://forums.slimdevices.com/showt...=1#post1053624
We'll see how that goes.

Still wondering if I should factory restore or not.

[rdeckard]

Don't mean to spam the thread, but I'm just about out of ideas.

Disabling wlan changed nothing.
I ultimately performed the factory restore, and updated to Community firmware. Nothing else.
Put back the IOGEAR WiFi bridge, let the Radio pull a DHCP IP, and all was OK for the day, but by last night, it had become sluggish/unresponsive again.
Reboot brought it back.

Removed WiFi bridge, attempted Wireless connection. Connected, found library, then icon went blue within 5 minutes.
When attempting to reconnect, it will only find the AP to which it was previously connected, but will not connect. Icon turns red.
Reboot brings it back.

This is looking less like a WiFi/Ethernet issue, and more like an actual hardware failure now.

A Touch, Controller, Duet, and Boom on the same network are all 100% OK during all of this.
No IP conflicts anywhere.

Could this be due to a bad power supply?
What's the best way to retrieve logs from the Radio?

Ready to pull the trigger on one of the many used Radios up on eBay.
Any other suggestions would be most appreciated.

[mrw]

What's the best way to retrieve logs from the Radio?

Login via SSH. Enable it in the advanced settings.
Log is /var/log/messages

Log does not survive a reboot, so copy it to the root user directory to preserve. Alternatively collect using scp.

I have occasionally had ‘sluggishness’, but not enough to investigate. Is there a common feature, e.g. a particular track or stream ?

[POMdev]

...
I ultimately performed the factory restore, and updated to Community firmware. Nothing else.
Put back the IOGEAR WiFi bridge, let the Radio pull a DHCP IP, and all was OK for the day, but by last night, it had become sluggish/unresponsive again.
Reboot brought it back.
...
This is looking less like a WiFi/Ethernet issue, and more like an actual hardware failure now.
...
Could this be due to a bad power supply?
What's the best way to retrieve logs from the Radio?

The sluggish/unresponsive complaint seems relevant. This could happen if some process is using all the processor time, or somehow all the system memory. Perhaps something misbehaving is hogging these resources. You could troubleshoot this using SSH to run 'top' to examine process CPU and memory values. The 'df' command displays how much flash memory is used and available. Of course, you have to log in via SSH before disconnection, run top, and keep the SSH window open until a failure. Hopefully, usage will "creep up" prior to the failure and you can identify a culprit. When the connection fails, so will the SSH connection, so the last result prior to failure will be still be displayed.

Installing wlanpoke and configuring it (adding "-d /etc/log/") for persistent log file storage can give you info about the system prior to failure you can retrieve after reboot.

You might consider running just the stock firmware. Also, try playing something completely different, e.g., a local music library, a different streaming service, etc. Try switching from LMS to mysqueezebox.com.

Regarding the power supply, my power supplies become intermittent at the barrel power connector and have to be resoldered every some years. But these failure result in discharged batteries, or outright power off or reboot outcomes.

Use 'tftp' to transfer log files out to a tftp server you run on your pc. Otherwise you can 'cat' the contents to the SSH terminal window and copy from there. The Radio's log files however are stored in non-persistent storage at /var/log, and are not that useful anyway. The 'dmesg' command yields more relevant info. You might add a line to wlanpoke to pipe a dmesg output to a text file in /etc/log on each failure.

If you are really ambitious, you can install a TTL serial connection to a TTL serial-USB adapter and use this to query the system even after a failure (but before a reboot).

[rdeckard]

Login via SSH. Enable it in the advanced settings.
Log is /var/log/messages

Log does not survive a reboot, so copy it to the root user directory to preserve. Alternatively collect using scp.

I have occasionally had ‘sluggishness’, but not enough to investigate. Is there a common feature, e.g. a particular track or stream ?

Hi mrw - thanks for the reply.
Not even playing anything at the time of failure, just letting it sit.
I even eliminated the WiFi bridge, and just have it directly connected to a switch now.
It's currently in the state where every button press/action is taking up to 10-15s to execute again.
Seems I can still SSH into it though, so will try to grab logs now.

[rdeckard]

The sluggish/unresponsive complaint seems relevant. This could happen if some process is using all the processor time, or somehow all the system memory. Perhaps something misbehaving is hogging these resources. You could troubleshoot this using SSH to run 'top' to examine process CPU and memory values. The 'df' command displays how much flash memory is used and available. Of course, you have to log in via SSH before disconnection, run top, and keep the SSH window open until a failure. Hopefully, usage will "creep up" prior to the failure and you can identify a culprit. When the connection fails, so will the SSH connection, so the last result prior to failure will be still be displayed.

Installing wlanpoke and configuring it (adding "-d /etc/log/") for persistent log file storage can give you info about the system prior to failure you can retrieve after reboot.

You might consider running just the stock firmware. Also, try playing something completely different, e.g., a local music library, a different streaming service, etc. Try switching from LMS to mysqueezebox.com.

Regarding the power supply, my power supplies become intermittent at the barrel power connector and have to be resoldered every some years. But these failure result in discharged batteries, or outright power off or reboot outcomes.

Use 'tftp' to transfer log files out to a tftp server you run on your pc. Otherwise you can 'cat' the contents to the SSH terminal window and copy from there. The Radio's log files however are stored in non-persistent storage at /var/log, and are not that useful anyway. The 'dmesg' command yields more relevant info. You might add a line to wlanpoke to pipe a dmesg output to a text file in /etc/log on each failure.

If you are really ambitious, you can install a TTL serial connection to a TTL serial-USB adapter and use this to query the system even after a failure (but before a reboot).

Hi POMdev. Appreciate the insight.

Have results from commands specified, as well as the messages file.
results.txt
messages.txt
Memory and CPU usage appear OK, but seeing lots of link up/down notices.
Otherwise, not exactly sure what I'm looking for.

Will factory restore again, and leave it on stock firmware.

[POMdev]

... Have results from commands specified, as well as the messages file. ...
Memory and CPU usage appear OK, but seeing lots of link up/down notices.
Will factory restore again, and leave it on stock firmware.

Do your results above show the status just before (or just after) a failure? Is this with the stock firmware?

Compared to one of my radios, your top result shows a lot of activity that mine doesn't. Yours:

[FONT=Courier New][SIZE=1]-- memory top line not in file --
CPU:   3% usr  56% sys   0% nic   0% idle   0% io  30% irq   9% sirq
Load average: 3.10 3.13 3.03 2/67 3177
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  740     2 root     SW<      0   0%  27% [ksdiorqd]
  712     2 root     RW<      0   0%  20% [AR6K Async]
  306     2 root     SW<      0   0%  20% [IRQ-9]
    9     2 root     SW<      0   0%  10% [sirq-tasklet/0]
  789   753 root     S     7300  12%  10% jive_alsa -d default -c dac -b 20000 -p 2 -s 16 -f 3
  753     1 root     R    31236  50%   6% /usr/bin/jive
 3177  3147 root     R     2800   5%   5% top[/SIZE][/FONT]

(Tip: "top -b -n1" just displays once to the console, preserving the first line.)

Mine (eth1 WLAN enabled and connected):

[FONT=Courier New][SIZE=1]Mem: 59836K used, 2276K free, 0K shrd, 5220K buff, 14736K cached
CPU:  11% usr  48% sys   0% nic  36% idle   0% io   1% irq   0% sirq
Load average: 1.38 1.59 1.57 1/70 15077
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  756     1 root     S    35200  57%  11% /usr/bin/jive
  967   756 root     S     7296  12%   7% jive_alsa -d default -c dac -b 20000 -p 2 -s 16 -f 3
  751     1 root     S     8912  14%   3% /bin/sh /etc/wlanpoke/wlanpoke.sh -W slow -d /etc/log/
    9     2 root     SW<      0   0%   2% [sirq-tasklet/0]
 5544     2 root     SW<      0   0%   2% [ksdiorqd]
12384 22176 root     R     2796   5%   2% top
  306     2 root     SW<      0   0%   1% [IRQ-9]
 5515     2 root     SW<      0   0%   1% [AR6K Async]
22103   698 root     S     2584   4%   1% dropbear -i[/SIZE][/FONT]

Your radio has really high %CPU for processes that have very low values on mine. The [ksdiorqd] process in particular is showing 27% CPU, the 30% irq 9% sirq (hardware and software interrupts), and [AR6K Async] entries are concerning. Are these values similar to those after rebooting?

I believe that 'ksdiorqd' is an identifier for the 'sdio_irq_thread' for SDIO cards and devices. I don't know whether the SDIO interface is used for the WLAN and/or Ethernet chips or not. The [AR6K Async] process suggests that the wireless chip is enabled and perhaps causing the trouble, although it shouldn't. Try the same after switching to WLAN. Try switching to Ethernet and disabling the WLAN driver. When you are "in the weeds" this far, you might as well try running wlanpoke from the console (RTM) and troubleshooting that at least to obtain more diagnostics.

At some point I can try Ethernet on my serially connected radio for a better answer.

[rdeckard]

Do your results above show the status just before (or just after) a failure? Is this with the stock firmware?

Compared to one of my radios, your top result shows a lot of activity that mine doesn't. Yours:

[FONT=Courier New][SIZE=1]-- memory top line not in file --
CPU:   3% usr  56% sys   0% nic   0% idle   0% io  30% irq   9% sirq
Load average: 3.10 3.13 3.03 2/67 3177
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  740     2 root     SW<      0   0%  27% [ksdiorqd]
  712     2 root     RW<      0   0%  20% [AR6K Async]
  306     2 root     SW<      0   0%  20% [IRQ-9]
    9     2 root     SW<      0   0%  10% [sirq-tasklet/0]
  789   753 root     S     7300  12%  10% jive_alsa -d default -c dac -b 20000 -p 2 -s 16 -f 3
  753     1 root     R    31236  50%   6% /usr/bin/jive
 3177  3147 root     R     2800   5%   5% top[/SIZE][/FONT]

(Tip: "top -b -n1" just displays once to the console, preserving the first line.)

Mine (eth1 WLAN enabled and connected):

[FONT=Courier New][SIZE=1]Mem: 59836K used, 2276K free, 0K shrd, 5220K buff, 14736K cached
CPU:  11% usr  48% sys   0% nic  36% idle   0% io   1% irq   0% sirq
Load average: 1.38 1.59 1.57 1/70 15077
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  756     1 root     S    35200  57%  11% /usr/bin/jive
  967   756 root     S     7296  12%   7% jive_alsa -d default -c dac -b 20000 -p 2 -s 16 -f 3
  751     1 root     S     8912  14%   3% /bin/sh /etc/wlanpoke/wlanpoke.sh -W slow -d /etc/log/
    9     2 root     SW<      0   0%   2% [sirq-tasklet/0]
 5544     2 root     SW<      0   0%   2% [ksdiorqd]
12384 22176 root     R     2796   5%   2% top
  306     2 root     SW<      0   0%   1% [IRQ-9]
 5515     2 root     SW<      0   0%   1% [AR6K Async]
22103   698 root     S     2584   4%   1% dropbear -i[/SIZE][/FONT]

Your radio has really high %CPU for processes that have very low values on mine. The [ksdiorqd] process in particular is showing 27% CPU, the 30% irq 9% sirq (hardware and software interrupts), and [AR6K Async] entries are concerning. Are these values similar to those after rebooting?

I believe that 'ksdiorqd' is an identifier for the 'sdio_irq_thread' for SDIO cards and devices. I don't know whether the SDIO interface is used for the WLAN and/or Ethernet chips or not. The [AR6K Async] process suggests that the wireless chip is enabled and perhaps causing the trouble, although it shouldn't. Try the same after switching to WLAN. Try switching to Ethernet and disabling the WLAN driver. When you are "in the weeds" this far, you might as well try running wlanpoke from the console (RTM) and troubleshooting that at least to obtain more diagnostics.

At some point I can try Ethernet on my serially connected radio for a better answer.

Not sure it's worth the trouble...
Factory-restored again.
Left it with stock firmware.
Wired Ethernet connection only.
"Connected to Ethernet" with DHCP IP.
Radio is previously registered to me on mysqueezebox.com, so let it continue with that account when prompted, and it immediately came online and connected to my local LMS server.
No other settings touched.
Went to lunch.
Came back less than an hour later, and it was already in the sluggish/unresponsive state.
This is now literally a new, out-of-the-box scenario, and I'm having the same problem.
Unless there's a different, more invasive factory reset procedure, I'm thinking this Radio is toast.

[mrw]

Came back less than an hour later, and it was already in the sluggish/unresponsive state.

Does it show the very high CPU usage for those wi-fi radio related tasks, which you saw before, while in this state ?

If so, might be worth trying to disable the wlan subsystem and seeing if the problem persists. I recall that you found a thread that shows how to do that.

[rdeckard]

Does it show the very high CPU usage for those wi-fi radio related tasks, which you saw before, while in this state ?

If so, might be worth trying to disable the wlan subsystem and seeing if the problem persists. I recall that you found a thread that shows how to do that.

Here is another top after rebooting and immediately disabling wlan:
top_after_restart_and_disabling_wlan.txt

Terminal output when disabling wlan:

# /etc/init.d/wlan stop
root: wlan: stopping
..unloading all
killall: recEvent: no process killed
root: wlan stopped

(Almost seems like nothing was done?)

As expected, working perfectly for the moment.
Stepping out to walk the doggo.
Will check again when I return.