Bugzilla – Bug 17253
Connection to mysqueezebox.com does not recover after DSL reconnect
Last modified: 2012-03-30 17:47:09 UTC
I am using a Squeezebox Radio, connected to mysqueezebox.com. I do not use a local server. When at night my DSL reconnects itself to the provider (acquiring a new IP address to the outside world) the Squeezeplay application on the Radio fails to refresh its connection to mysqueezebox.com, although using the commandline tools of the embedded linux on the device works flawlessly. The Radio is connected via WLAN to a Netgear-Router ("A"), doing some NAT'ing for my apartment. This Router has a statically configured IP to a second router ("B"), which does some NAT'ing for all apartments in the house. Router B is using DSL to connect the house to an Internet provider. It forces a reconnect each night at 04:00, typically acquiring a new internet address in this process. The Radio uses the following Firmware Revision: # cat /etc/squeezeos.version 7.5.4 r9408 root@vdc01b01centos01 Wed Apr 6 11:44:27 MDT 2011 # cat /etc/version 201104061140 The effect of the bug is, that after the DSL reconnect the connection to mysqueezebox.com consistently fails. Almost each interaction with the buttons of the radio results in a popup, alerting me of an attempt to contact mysqueezebox.com. Playback of internet radio stations is not working. It seems there is no way of recovering this situation, except for a reboot of the Radio. When the radio is in this failure state, using ssh to connect to the radio and then trying the command "ping mysqueezebox.com" shows, that there is no fundamental network problem. The ping succeeds, DNS resolving works, ping responds. It is possible to create connections to servers on the internet. So the general network structure is OK, but the squeezeplay application completely fails to recover its connection to mysqueezebox.com. Especially annoying for me is, that I want to use the Radio as an Alarm Clock in the morning. Since the radio loses its connection to mysqueezebox.com at about 4:00 in the night (when I am hopefully sleeping and unable to reboot the Radio) and it fails to recover its connection until the morning, I consistently get woken up with a fallback alarm sound, and the Alarm Interval for the Snooze functionality is 1 Minute (which sucks, I have configured it to 5 Minutes at mysqueezebox.com). Since this bug directly affects advertized functionality (i.e. Alarm Clock and regular playback of Internet Radio Stations) I have set the severity to "major". I'd greatly appreciate a fix for this.
I forgot to add: When the Radio is in the nonfunctional state, the "Diagnostics" menu item claims, that the connection to mysqueezebox.com is OK, that Ping succeeds and the contact to the two ports is OK. The IP address of mysqueezebox.com is not necessarily the same as the IP address shown when using "ping" on the commandline.
Created attachment 7314 [details] output of ngrep -x host <radio-ip> when in failure state I have the impression that in the nonfunctional state the tcp connection for the slim protocol is stuck somehow. When trying to switch to a local server the radio does discovery, does some JSON requests but does not create a connection for the slim protocol. Attached is the output of "ngrep -x host 192.168.23.101" (...101 is the IP of the radio) after trying to reconnect to the local server when in failed state.
(In reply to comment #2) > Attached is the output of "ngrep -x host 192.168.23.101" (...101 is the IP of > the radio) after trying to reconnect to the local server when in failed state. Do clarify: by "reconnect" I meant switching from the (now nonfunctional) mysqueezebox.com server to a local server on my laptop via the Radio GUI.
Created attachment 7315 [details] shortened log of a working switch to a local squeezebox server. Just to contrast against the previous log: After rebooting the radio the connection to mysqueezebox.com works and a a switch to my local server looks like this. Note that before the first JSON request a connection to port 3483 on my laptop is created, exchanging information on the current state of the player. The log is shortened a bit, the interesting points are at the beginning.
Please download and re-test this bug on a newer version of SqueezePlay. If you are still able to replicate this bug, then feel free to reopen the bug.
(In reply to comment #5) > Please download and re-test this bug on a newer version of SqueezePlay. If you > are still able to replicate this bug, then feel free to reopen the bug. I have kept the firmware up to date in the last few months and the behavior has not improved. Please note that I am familiar with embedded linux on various platforms and might be able to help you tracking down the bug. So if you have specific questions please feel free to ask. Reopening this bug.
(In reply to comment #6) > I have kept the firmware up to date in the last few months and the behavior has > not improved. To clarify, currently the radio uses the Software revision 7.7.1 r9557. I hope this helps.
The problem persists with 7.7.2 r9663