Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 14
  1. #1
    Junior Member
    Join Date
    Oct 2018
    Posts
    10

    Work-around for SqueezeBoxRadio wifi drop-out

    Hi,
    I have had recent problems with a SqueezeBoxRadio that had been 100% reliable on a wifi link for several years and then suddenly started disconnecting and required either network repair, and more often reboot to get connectivity up again. I assumed it must have been new wifi interference out of my control. If I placed the unit directly in front of my AP. It did not happen, but when I placed it back into the position I wanted it (at some distance) it started with disconnects.

    I noticed others in related posts had similar issues. So I worked on this a little. Hope someone else might find this useful....

    During investigations, I tried with little success to use ssh on the client while this was happening and even tried saving logs to another file to try and capture what was occurring. It all proved ineffective. So finally I attached to the serial interface on the SqueezeBoxRadio and waited for disconnect.
    It seems that when these disconnects occur it is not possible to simply restart the IP layer or for that matter the wpa_supplicant. Both are dependent on the the atheros wireless driver. This seems to have a bug that places it into a uni-directional state. Traffic out from the IP layer but responses do not make it to the host.
    Therefore to avoid debugging the wireless code ???? I came up with a work around:
    Essentially a simple ping based bidirectional forwarding detection mechanism, that regularly pings the squeeze server according to the info in the server config file, and if pings fail, it unloads the entire atheros driver, reloads again aquires a new IP and actually the higher layer (Squeezeplay) rides this out and the connection loss is invisible to the user application.

    Nasty but effective. To kick off the script I modified /etc/network/udhcpc_action. This now starts an instance of my BFD.sh script every time a dhcp lease is acquired. It also looks for an instance of the script BFD.sh pid file, to ensure it does not attempt to start multiple instances each time a dhcp renew occurs. The BFD.sh script does a simple job of cleaning up its own pid files and runs continuously until a disconnect occurs. It then reloads the driver modules and then exits, waits for dhcp to acquire an IP address and is then restarted by udhcpc_action, only when IP connectivity should be re-established.

    /etc/network/BFD.sh
    Code:
    #!/bin/sh
    
    loop="true"
    
    if test -f "/var/run/BFD.pid"; then
    	for pr_num in $(pidof BFD.sh); do
    		if [ $pr_num != $$ ]; then
    			kill -9 $pr_num
    		fi
    	done
    	rm /var/run/BFD.pid
    fi
    /usr/bin/logger "BFD Daemon started with PID: "$$
    echo $$ > /var/run/BFD.pid
    
    server=$(awk -F"serverInit="  '{print $2}' /etc/squeezeplay/userpath/settings/Playback.lua | awk -F"," '{print $2}' | cut -d '"' -f2)
    
    while [ $loop == "true" ]
    do
        ping -W 1 -w 10 -c 5 $server > /dev/null
        if [ $? -ne 0 ]; then
          	/usr/bin/logger "Ping Bidirectional Forwarding Detection failed: Restarting wlan."
          	/etc/init.d/wlan stop
          	sleep 2
          	/etc/init.d/wlan start
          	rm /var/run/BFD.pid
          	udhcpc -R -a -p /var/run/udhcpc.eth1.pid -b --syslog -i eth1 -H SqueezeboxRadio -s /etc/network/udhcpc_action
          	#dropbear -i
          	loop="false"
        else
        	loop="true"
        fi
        	sleep 5
    done
    modified /etc/network/udhcpc_action
    Code:
    #!/bin/sh
    
    # udhcpc script edited by Tim Riker <Tim@Rikers.org>
    # zcip integration idea from here: http://osdir.com/ml/network.zeroconf.workers/2005-06/msg00000.html
    
    [ -z "$1" ] && echo "Error: should be called from udhcpc" && exit 1
    
    RESOLV_CONF="/etc/resolv.conf"
    [ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
    [ -n "$subnet" ] && NETMASK="netmask $subnet"
    
    /usr/bin/logger "udhcpc_action $interface $1 ip=$ip"
    
    case "$1" in
    	deconfig)
    		killall zcip > /dev/null
    		/sbin/ifconfig $interface 0.0.0.0
    		;;
    
    	fail|leasefail)
    		killall zcip > /dev/null
    # -v is needed to work around a bug in zcip - probably fixed in newer version
    		/sbin/zcip -v $interface /etc/network/zcip_action > /dev/null &
    		;;
    
    	renew|bound|zeroconf)
    		killall zcip > /dev/null
    		/sbin/ifconfig $interface $ip $BROADCAST $NETMASK
    
    		while route del default gw 0.0.0.0 dev $interface ; do
    			:
    		done
    
    		if [ -n "$router" ] ; then
    			metric=0
    			for i in $router ; do
    				route add default gw $i dev $interface metric $metric
    				metric=$metric+1
    			done
    		else
    			route add default dev $interface
    		fi
    
    		echo -n > $RESOLV_CONF
    		[ -n "$domain" ] && echo search $domain >> $RESOLV_CONF
    		for i in $dns ; do
    			echo adding dns $i
    			echo nameserver $i >> $RESOLV_CONF
    		done
    		if [ ! -f "/var/run/BFD.pid" ]; then
    			(/etc/network/BFD.sh &) &
    		fi
    		;;
    esac
    
    exit 0

  2. #2
    Senior Member
    Join Date
    Nov 2012
    Location
    Southern California
    Posts
    231
    Interesting solution. Have you seen the wlanpoke script developed by POMDEV? See

    https://forums.slimdevices.com/showt...lanpoke)/page4

    POMDEV describes the fix as:
    The script does not fix the disruption issue. Instead, it restarts the wireless radio after a disruption has been detected, frequently quickly enough so that music that has been downloaded to the radio does not "run out" before the radio reconnects.
    I am no expert, so I am glad there are smart people trying to create solution to prevent the SB radios from just being a clock.

  3. #3
    Senior Member
    Join Date
    Jul 2007
    Location
    Boston, MA, USA
    Posts
    184
    Nice to have multiple ideas/alternatives (this one, wlanpoke), thank you for taking the time to put workarounds together.

    Would it be better in your script to ping the gateway instead of the squeezebox server (which might go down for other reasons)?

    e.g. "ip r |grep default| cut -d' ' -f 3"

    I realize if the sb server goes down you aren't playing music anyway, but still.... Just a thought really, ignore as you see fit.

    TomS
    Last edited by TomS; 2021-09-10 at 07:28.
    SB3(1), Boom(2), Radio(3), piCorePlayer (1)

  4. #4
    Junior Member
    Join Date
    Oct 2018
    Posts
    10
    Quote Originally Posted by P Nelson View Post
    Have you seen the wlanpoke script developed by POMDEV?
    I had not until I posted my own solution. I did then take a look at wlanpoke (typical that I didn't see it before the effort but hey ho), but in all honesty and with all due respect I found a 'sledgehammer to crack a nut'. I'm sure it is wonderful and very effective, but as I already worked through my own at this point and its working and is seems to not cause any resets or timeouts of SqueezePlay, I'm sticking with the simple short scripts until otherwise frustrated.
    All the best

  5. #5
    Junior Member
    Join Date
    Oct 2018
    Posts
    10
    Quote Originally Posted by TomS View Post
    Would it be better in your script to ping the gateway instead of the squeezebox server (which might go down for other reasons)?
    As you like, I think its pretty simple to even hardcode whatever device you might consider suitable in terms of a reach-ability test. At the end of the day using ping in this way is never ideal, after all under heavy interference it may be that packet loss will trigger a restart, but I'm living with the risk. But it seems that the driver problem is itself triggered by packet loss and dubious wireless conditions, so .... go figure. I just wanted my radio to work again

    No doubt the ideal solution would be to figure out why the driver is locking up. Link Layer retransmissions causing buffer overruns?? Unfortunately the firmware is a binary and I didn't have the desire to open that can of worms anyway. Its a workaround after all.

  6. #6
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    899
    Quote Originally Posted by aidy_w View Post
    Hi,
    Both are dependent on the the atheros wireless driver. This seems to have a bug that places it into a uni-directional state. Traffic out from the IP layer but responses do not make it to the host.
    Not just IP, I think.

    I did manage, once or twice, to get my Radio into this state, probably due to very poor positioning/bad signal strength relative to the AP I had set up [1].

    I observed that it would send reassociation requests to the AP just fine, but completely ignored the AP’s positive responses. This was evident from the AP’s log.

    It’s not easy for me to reproduce the conditions and examine further. Particularly as I generally use the Radio for its intended purpose of listening to music.

    [1] Tinkering with hostapd on a Raspberry Pi.

  7. #7
    Senior Member Tony T's Avatar
    Join Date
    Nov 2009
    Posts
    1,178
    Simple, thanks for this.
    wlanpoke is effective, and has a lot of logging to help in investigation of the problem to assist in a true fix, but unfortunately, a true fix, as you noted, requires an updated wireless driver (not going to happen), or a new-user created one (don't see that happening either).
    Never took the time to really understand the script in wlanpoke, but yours is short enough for me to comprehend (thanks).
    Now that wlanpoke is working for me (needed to use the -x switch for me), i'm going to disable it and give your workaround a try.
    BTW, what does BFD stand for?

    Edit: Didn't work for me. WiFi dropped and didn't reconnect, then after I rebooted the radio, it rebooted on its own twice within the next 30 minutes.
    Last edited by Tony T; 2021-09-26 at 15:03.
    Tony
     SBTouch ♪ SBRadio ♬

  8. #8
    Junior Member
    Join Date
    Nov 2017
    Posts
    4
    I've the same problem with disconnects, but here's the rub... My Squeezebox Radio is cabled into the nearby wifi repeater. I'm not sure the issue is totally in the wifi drivers, it seems to be a problem with the network stack in general. Any idea how I could modify this the work on an ethernet connection?

  9. #9
    Senior Member
    Join Date
    Nov 2012
    Location
    Southern California
    Posts
    231
    Quote Originally Posted by Chz View Post
    I've the same problem with disconnects, but here's the rub... My Squeezebox Radio is cabled into the nearby wifi repeater. I'm not sure the issue is totally in the wifi drivers, it seems to be a problem with the network stack in general. Any idea how I could modify this the work on an ethernet connection?
    What brand and model of wifi repeater are you using? Are you sure the Radio is connecting via ethernet? The symbol will change to a line with arrows.
    I use a tplink nano router in ethernet bridge or client mode and not using the wifi repeater mode and have not had any problems. Others have used a vonets.

  10. #10
    Junior Member
    Join Date
    Aug 2019
    Posts
    18
    Quote Originally Posted by Chz View Post
    I've the same problem with disconnects, but here's the rub... My Squeezebox Radio is cabled into the nearby wifi repeater. I'm not sure the issue is totally in the wifi drivers, it seems to be a problem with the network stack in general. Any idea how I could modify this the work on an ethernet connection?
    Purely anecdotal, but I had sporadic but numerous wifi outages on both a Radio and a Receiver (years apart) as a result of a dying, but not dead, PSU. PSU replaced, no more wifi outages. If you have another working Radio, you could try swapping the PSUs and see if the fault stays with that Radio.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •