PDA

View Full Version : Squeezebox 2 "unfriendly" with (wired) network connectivity



Jeff
2005-12-12, 09:28
Hi,

I have a bunch of network devices in my home; a rough count of 20 or so network devices exist.

Recently, I replaced my networking switch. So this meant shutting down the old switch, installing the new switch, configuring, and connecting the cables.

Later, I updated the switch software, which required rebooting the switch (total downtime was around 3-4 minutes).

In each of these cases, all of my network devices CAME BACK AUTOMATICALLY except for the Squeezeboxes. The Squeezeboxes (all 3 of them) each required that I either power cycle the boxes or hold down the power button to do a hard reboot of the box.

My question is: If I have a network of 20 devices, of all different kinds (automation system hardware, UPSes, IP/KVP switch, a number of different computers/operating systems, etc), why is it that ONLY the Squeezeboxes won't "come back automatically"?

Or, asked another way: Shouldn't the Squeezebox monitor it's Ethernet circuit and, if it drops out, reset itself when it comes back?

I thought I'd post here before posting to the bug list, in case anyone has any insight.

-- Jeff

dean
2005-12-12, 10:49
On Dec 12, 2005, at 8:28 AM, Jeff wrote:
> Or, asked another way: Shouldn't the Squeezebox monitor it's Ethernet
> circuit and, if it drops out, reset itself when it comes back?

It absolutely should and as far as I can tell, does.

If I unplug the ethernet from my SB2, after a few seconds it displays
an error message. Wait a few minutes, then plug it back in and it
reconnects just fine.

Can you reproduce the problem in a way that we can do it here too?
Can you also provide details about your network setup (devices,
configuration?)

Thanks,

dean

Jeff
2005-12-12, 13:58
On Dec 12, 2005, at 8:28 AM, Jeff wrote:[color=blue]
It absolutely should and as far as I can tell, does.

Can you reproduce the problem in a way that we can do it here too?

Can you also provide details about your network setup (devices,
configuration?)

Thanks,

dean

Oh, you're right. It's slightly more involved, sorry 'bout that!

1) Disconnect SlimServer machine from the network. Wait 5-10 seconds. Squeezebox display goes dark.

2) Disconnect Squeezebox from the network. Screen remains dark.

3) Wait 60 seconds or so.

4) Connect Squeezebox to the network. Wait 30 seconds or so.

5) Connect SlimServer machine to the network.

Squeezebox display remains dark, and doesn't come back. You must power cycle the unit or do a full reset (power button held down) to get things talkin' again.

Apparently, when my switch comes back to life, it appears to take a few more seconds to get the server ports (GB ports) up than it does the 100mb ports. So the Squeezebox appears to see the link, can't chat with my SlimServer machine (UNIX), and permanently gives up.

And that would by why I've also seen this problem on power failures to the house: the UNIX machine takes a whole lot longer to come back than the Squeezebox. The Squeezebox comes up, sees no UNIX server, and then permanently gives up.

Since the Squeezebox knows the server it previously connected with, shouldn't it retry that connection from time to time (every 10-15 seconds or so), to see if the music server is back alive? It shouldn't flood the network, but it should retry every so often continuously unless told otherwise via the remote or something ...

Certainly, other equipment I have that requires a server connection does this. And my own software (like SlimServerMod, the module that combines a NetLinx automation system with the SlimServer software via the CLI) does this too: If it looses connection to the SlimServer CLI on port 9090, it tries again every so often until it reconnects.

-- Jeff

dean
2005-12-12, 14:08
Hi Jeff,


On Dec 12, 2005, at 12:58 PM, Jeff wrote:
> 1) Disconnect SlimServer machine from the network. Wait 5-10 seconds.
> Squeezebox display goes dark.
>
> 2) Disconnect Squeezebox from the network. Screen remains dark.
>
> 3) Wait 60 seconds or so.
>
> 4) Connect Squeezebox to the network. Wait 30 seconds or so.
>
> 5) Connect SlimServer machine to the network.

Alas, those steps don't do it for me here. Is there some other trick
I missed?

> Since the Squeezebox knows the server it previously connected with,
> shouldn't it retry that connection from time to time (every 10-15
> seconds or so), to see if the music server is back alive? It
> shouldn't
> flood the network, but it should retry every so often continuously
> unless told otherwise via the remote or something ...
It does exactly that. Or at least it does here...

Some questions...

Are your devices using DHCP or static addresses? Are the addresses
changing? Do you have the ability to do a packet capture?

Jeff
2005-12-12, 14:20
Hi Dean,


Alas, those steps don't do it for me here. Is there some other trick
I missed?

.....

Some questions...

Are your devices using DHCP or static addresses? Are the addresses
changing? Do you have the ability to do a packet capture?

I don't get it. This reproduces so easily for me!

UNIX box has a static address. Squeezeboxes have dynamic addresses via DHCP. It's possible that the router isn't coming back immediately with a DHCP address, perhaps that's involved?

If the Squeezebox doesn't lose power, but does lose link connectivity, and then the link comes back (but the Squeezebox can't immediately get a DHCP address), what happens? Does the Squeezebox retry getting a DHCP address every so often until success, at which point it tries to contact the server? Or does something else happen?

This reproduces 100% of the time for me, so something's different.

This could be a DHCP issue: My router won't (always) give out a DHCP address unless the router can save it's DHCP database to a remote host (the UNIX system). By taking the UNIX system offline momentarily, then I might have forced the router to cease honoring DHCP until the UNIX server came back.

So, end result: If the Squeezebox can't get a DHCP address and then permanently gives up, I'd see the same symptom.

Does this help? I could give the Squeezeboxes permanent addresses if that would help to isolate ...

-- Jeff

dean
2005-12-12, 14:33
On Dec 12, 2005, at 1:20 PM, Jeff wrote:
> I don't get it. This reproduces so easily for me!
Frustrating... grrr...

>
> UNIX box has a static address. Squeezeboxes have dynamic addresses
> via
> DHCP. It's possible that the router isn't coming back immediately
> with
> a DHCP address, perhaps that's involved?
Same setup here, static server, dynamic client. My DHCP server is
dhcpd running on the same machine as the server.

> If the Squeezebox doesn't lose power, but does lose link connectivity,
> and then the link comes back (but the Squeezebox can't immediately get
> a DHCP address), what happens? Does the Squeezebox retry getting a
> DHCP address every so often until success, at which point it tries to
> contact the server?
Yes.

> This could be a DHCP issue: My router won't (always) give out a DHCP
> address unless the router can save it's DHCP database to a remote host
> (the UNIX system). By taking the UNIX system offline momentarily,
> then
> I might have forced the router to cease honoring DHCP until the UNIX
> server came back.
>
> So, end result: If the Squeezebox can't get a DHCP address and then
> permanently gives up, I'd see the same symptom.
The thing is that it doesn't give up. It just keeps trying.

What would be useful would be to get a packet dump from the server
when it's in the state of not being able to connect.

Also, without rebooting the player, what happens if you go back to
the main menu and try to reconnect? What happens if you go through
setup again?



> Does this help? I could give the Squeezeboxes permanent addresses if
> that would help to isolate ...
That's worth a shot.

Jeff
2005-12-12, 14:45
The thing is that it doesn't give up. It just keeps trying.

What would be useful would be to get a packet dump from the server when it's in the state of not being able to connect.

Also, without rebooting the player, what happens if you go back to the main menu and try to reconnect? What happens if you go through setup again?

This, obviously, is going to take a little bit of time to isolate, and isn't as obviously simple as I thought. Sigh. That's cool; I'll spend the time to get to the bottom of this. But it sure looked trivially reproducable to me ...

Without rebooting the player, I'm dead. The screen is dark. If I hit "power", I get an Ethernet connectivity error, and I can't get beyond this without power cycling or holding down the power button. Once I reproduce this, how do I get to the "main menu" without rebooting?

Since everything is online at that point, I'm sure everything will work if I go through setup, but I'm willing to try everything to avoid having to try and capture the packets. I don't do that very often, so I'm a bit rusty at it.

Unfortunately, my UNIX box is the only host I can easily capture packets from, and it is the one that hosts SlimServer as well (and is thus being taken offline for these tests). If I can sniff the Squeezebox by MAC address, I'd at least be able to see if it is, indeed, trying again. Please respond with how to get to the "main menu", and if that doesn't give useful information, I'll start a-sniffin'.

dean
2005-12-12, 15:00
On Dec 12, 2005, at 1:45 PM, Jeff wrote:
> dean Wrote:
>> The thing is that it doesn't give up. It just keeps trying.
>>
>> What would be useful would be to get a packet dump from the server
>> when
>> it's in the state of not being able to connect.
>>
>> Also, without rebooting the player, what happens if you go back to
>> the
>> main menu and try to reconnect? What happens if you go through setup
>> again?
>
> This, obviously, is going to take a little bit of time to isolate, and
> isn't as obviously simple as I thought. Sigh. That's cool; I'll
> spend
> the time to get to the bottom of this. But it sure looked trivially
> reproducable to me ...
Thanks for the effort.

> Without rebooting the player, I'm dead. The screen is dark. If I hit
> "power", I get an Ethernet connectivity error, and I can't get beyond
> this without power cycling or holding down the power button.
You should be able to press the left arrow button to get back to the
menu. Does this work?

> Since everything is online at that point, I'm sure everything will
> work
> if I go through setup, but I'm willing to try everything to avoid
> having
> to try and capture the packets. I don't do that very often, so I'm a
> bit rusty at it.
Thanks.

> Unfortunately, my UNIX box is the only host I can easily capture
> packets from, and it is the one that hosts SlimServer as well (and is
> thus being taken offline for these tests). If I can sniff the
> Squeezebox by MAC address, I'd at least be able to see if it is,
> indeed, trying again. Please respond with how to get to the "main
> menu", and if that doesn't give useful information, I'll start
> a-sniffin'.
You should be able just press left.

Also, what version of firmware are you running?

Jeff
2005-12-16, 10:19
Also, what version of firmware are you running?

I'm still looking at this.

I'm running what ever version of firmware ships with "6.2.1 - 5194 - Linux - EN - utf8". I'm not sure how to check, but I think this answers your question.

I rearranged my network infrastructure to put my UNIX box and one of my Squeezeboxes on a hub (it was on a switch, where I couldn't capture packets). I also figured out how to run and use Ethereal from Linux, and I got that all squared away. Then I installed SlimServer to my Windows box so I could bring that box offline to reproduce and, much to my disappointment, the problem did NOT reproduce from my Windows server.

This leads me to believe (I haven't verified this yet) that it might be a DHCP issue, but I can't capture packets to find out since my Linux box (where I capture packets from) needs to be taken offline to replicate the original problem.

I guess I see two choices:

1) Eliminate DHCP from the equation by reconfiguring the box to get a static address, then try to reproduce, or

2) Get some packet sniffing software installed on Windows, reconfigure my network to capture from there, and then replicate the original problem.

Is #2 easy to do? Any suggestions for such software?

Would trying #1 be a reasonable approach?

MrC
2005-12-16, 10:36
Is #2 easy to do? Any suggestions for such software?

Yes, its very simple. Get and install:

1) winpcap : http://www.winpcap.org/
2) Ethereal: http://www.ethereal.com/

snarlydwarf
2005-12-16, 10:36
There is a version of Ethereal for Windows.

http://www.ethereal.com/

My guess is that it's related to something in the switch that for Mysterious Reasons doesn't like seeing a DHCP packet too soon after reboot... but why it would be so upset that it would ignore further ones is curious.

It will probably work fine with the hub.

MrC
2005-12-16, 10:41
I'm running what ever version of firmware ships with "6.2.1 - 5194 - Linux - EN - utf8". I'm not sure how to check, but I think this answers your question.
No, that's the slimserver software version and locale. Instead, look just above that info for Player Firmware Version in the web or look at Settings->Information->Player Information on the SB.

Jeff
2005-12-16, 15:49
No, that's the slimserver software version and locale. Instead, look just above that info for Player Firmware Version in the web or look at Settings->Information->Player Information on the SB.

What's the point? Firmware versions and software versions are sync'ed; that will answer Dean's question.

Just to satisfy others out there (since Dean should know), the firmware version shipping with SlimServer 6.2.1 is 28.

-- Jeff

MrC
2005-12-16, 16:11
What's the point? Firmware versions and software versions are sync'ed; that will answer Dean's question.

Just to satisfy others out there (since Dean should know), the firmware version shipping with SlimServer 6.2.1 is 28.

I was simply offering a How To in response to your statement that you didn't know how to check the firmware. I didn't suggest that you needed to do anything.

Russell Mulcahy
2005-12-17, 10:27
This may (not) be relevant - my firmware version is reported as 40 for
the same 5.2.1 build! Am I *that* far ahead ;-)

I also have a problem where my SB2 "can't find slimserver" after a power
on or restart. Pressing "left" and resetting up the connection works
every time. This is with a Belkin F5D7230v4 router and using DCHP and no
encryption.

In my case at least, the firmware version isn't sync'd that well. Not
sure what this means, though.

Russell.

Jeff wrote:

>MrC Wrote:
>
>
>>No, that's the slimserver software version and locale. Instead, look
>>just above that info for Player Firmware Version in the web or look at
>>Settings->Information->Player Information on the SB.
>>
>>
>
>What's the point? Firmware versions and software versions are sync'ed;
>that will answer Dean's question.
>
>Just to satisfy others out there (since Dean should know), the firmware
>version shipping with SlimServer 6.2.1 is 28.
>
>-- Jeff
>
>
>
>

Richie
2005-12-17, 11:08
On 17/12/05, Russell Mulcahy <Russell.News (AT) blueyonder (DOT) co.uk> wrote:
> This may (not) be relevant - my firmware version is reported as 40 for the
> same 5.2.1 build! Am I *that* far ahead ;-)

No you're not ahead, you have a SB1 if the firmware is version 40.

I hope no one sold it to you pretending it was a SB2.

Richard

Russell Mulcahy
2005-12-18, 08:14
Er, no. I am just confused. Less so now, thanks.

Thanks,

Russell.

Richie wrote:

>On 17/12/05, Russell Mulcahy <Russell.News (AT) blueyonder (DOT) co.uk> wrote:
>
>
>> This may (not) be relevant - my firmware version is reported as 40 for the
>>same 5.2.1 build! Am I *that* far ahead ;-)
>>
>>
>
>No you're not ahead, you have a SB1 if the firmware is version 40.
>
>I hope no one sold it to you pretending it was a SB2.
>
>Richard
>
>