This consistently happens to me as well on 6.5.1.

Does disconnecting the power to the squeezebox and reconnecting it also fix the problem?  I'm not suggesting this as a workaround, but just trying to get some additional diagnostic information.

I will try again as soon as it happens again. However I am pretty sure that not. In the past (before I figured out that was sufficient to go through the setup menus to regain connectivity) I used to disconnect the power and put it in again and since that didn't work I went on with a factory reset everytime :-(. However this was with an older version of the firmware.

I'll try again ith current firmware, if that helps. Thanks

I'd also be interested to know what kind of wireless access point or router you're using.

A Linksys WAP54G

Steven could you see if we have one of these WAPs, and if not order one?

It happened, again. UNfortunately I was too fast on the remote so I don't know what exactly triggered the Squeezebox to come out from the dead status and start working again. However I am almost 100% sure that in the meantime the TCP-IP address of the unuit had changed. NOw I have written down so I'll be able to say for sure when it happens again, but it could be a reasonable explanation if somehow the firmware is not able to renegotiate automatically a new ip address if for any reason the old one is lost. 

Alessandro, assuming you have been using DHCP, have you tried setting up the Squeezebox with a static IP address to see if it makes a difference?  Since the WAP54G is only an access point what have you been using as your DHCP server?  

Yes, I am using DHCP. I can try to setup the Squeezebox with fixed IP address but since I am not an network expert I am in doubt wheter it's enough to do it on the squeezebox or do I have to fix it also on the router.

My configuration is that I have a router connected to the ADSL modem. This router is provided by the telephone company and I have absolutely no control over it. I believe the DHCP is built in the router. Then router had 4 ports. I have 2 PCs and a printer connected to those ports. Then I have a switch connected to the last port providing additional 4 ports. To one of the ports of the switch I have connected one more PC (actually that's the one running the slimserver) and to another port I have connected the Linksys WAP. FInally I connect wirelessly trhough the WAP 2 notebooks, 1 media center and the squeezebox (sometimes also a PDA and a smartphone). 

What perplexes me is that of all those devices the squeezeox is the only one loosing the connection. TO be fare all the other devices are usually turned off or in stand-by. I am not usre what the state of the squeezebox is. I turn the squeezebox off with the power button in the remote, but then the RSS feeds are displayed on the screen. So I imagine that the squeezebox is not really off, otherwise it couldn't receive the feeds, and that the connection is always on.

Even if IP adresses change shouldn't the squeeezebox be able to renogiate a new address without having to go through the setup?

I am also getting this issue of the SB3 hanging and sometimes actually having to remove the power and go through the wireless setup completely, other times just turning back on it will renegotiate the wireless settings. Becoming a real pain becuase my father (his SB3) is not tecnnical and I have to go down everytime this happens.

For your reference we are using a linksys WAG54GS, we do not use the slim server only the squeeze network.

I will set a static IP address on this tonight to see if it helps the issue.

By the way how is the firmware upgraded on the SB3?

Regards
Jonathan Fry

Jonathan, the firmware is updated by holding down the brightness button on the remote for a few seconds.  More information can be found here http://wiki.slimdevices.com/index.cgi?PlayerFirmware.  Since you only use the Squeezebox with SlimServer you may be affected by bug 5171.  Would it be possible for you to set up a temporary SlimServer to connect to then switch to SqueezeNetwork and see if the problem persists?

Alessandro, you may want to discuss these issues with support at http://www.slimdevices.com/su_tech.html  The issues you describe all sound signal strength related to me.  You might also want to take a look through http://wiki.slimdevices.com/index.cgi?NetworkProblemsSecondGuide especially the interference section.  

steven thanks for the links i will read it as soon as i am back from vacation. however those links might help me figuring out why sometimes the connection is lost but the problem remains that the sb3 doesn't automatically recover. It should be able to do that without requiring running the setup again. For me that's a bug of the communication firmware, don't you agree? If your communication firmware requires that never there are interferences or drop out in order to work than i would say it's a pretty weak one. Will you please consider whether something is wrong with the recovery mechanism? many users are conplaining about it. Thanks.

OK, back at home and tried what described in those links.

1. I have an average signal strenght of 70%
2. Tried network test and I get 100% up to 2500 kbps (then I stopped trying)
3. Used networkstumbler. ONly one other network is in the vicinity (it is a residential neigborhood with villas far form each other). MY hetwrok is using channel 11 the othe rone is using channel 7, so no conflicts there.

I still think you sould ocnsider the possibility that the implementation of the communictaion protocol on the SB3 might be fragile. Other devices on the network does not loose the connection, or at leats coming out of stand-by are able to get the new IP address if this is changed. Couldhve it to do with the fact that running the RS-feed plug in in fact the device does never go in stand-by (just a wild guess)?

Thanks.

We completely believe that you're seeing a problem, and we're totally open to the possibility that the network stack is, as you say, 'fragile'.  That said, in the last couple years of development on the Squeezebox 2/3 firmware, we've done a ton of work to improve the robustness of the connection.  Our support team rarely sees issues like this with the latest firmware versions.

We are committed to fixing any remaining problems.  We will order WAP54G since we don't appear to have one in our inventory and see if we can reproduce your problem with it.

I have two wireless SB3 units, and both exhibit the following behaviour.

During the day, each will occasionally lose wireless connectivity. That's to be expected -- especially if the microwave oven is in use. I also have a pair of Panasonic 5.8GHz KX-TG5050 cordless phones.

If the loss is short enough, the unit will recover. If the unit was off (showing the power off screen saver), and the loss is lengthy, the unit appears to go quiet, with a blank display and doesn't recover connectivity. (If the unit was on [eg playing music], and the loss is lengthy, the display is not blank, and the unit doesn't recover connectivity.)

If I then take the remote, and hold the power button, the unit reboots and immediately regains connectivity.

Since a reboot immediately regains connectivity, the wireless signal path must be good by that time!

I was previously running 6.5.1 and have just upgraded to 6.5.4 with the same behaviour present in both versions.

Note that I experience the failure to re-connect both when the unit is off, or even when the unit is playing music, provided the outage is long enough.


I have three WRT54GLv1.1 routers and one WRT54Gv4 (Broadcom BCM5352EKPB Chipset). All run v4.71.1, Hyperwrt 2.1b1 + Thibor15c.

Interesting notes:

o The first wireless SB3 is located on the ground floor near the kitchen about 8m from the WRT54GLv1.1. The WRT54GLv1.1 is within 1m of the microwave oven, and a 5.8GHz cordless phone base station. When associated with this particular WRT54GLv1.1 I notice the outages _very_ often, even when the microwave oven is _not_ in use. This proved to be so frustrating, particularly when playing music, that I forced the SB3 to associate with a _different_ WRT54GLv1.1 that is about 16m away. That WRT54GLv1.1 is about 8m away from both the microwave and the 5.8GHz base station. With this, the situation is improved to be no worse than with my second SB3.

o The second SB3 is on the middle floor of my house, but within 4m of my second 5.8GHz cordless phone base station. This unit associates with a WRT54Gv4 located in the upper floor. Outages occur with this unit too.

o Unscientifically, I suspect the outage will occur within 6 hours of power on.

o I have one wired-only SB3 that is directly connected to my router, and that unit has never exhibited this kind of outage.

I am happy to assist with debugging and requests for more information.

Oh, yes, I forgot to mention, I run my SB3s with static IP addresses. I do not use DHCP.

For security settings on the routers, I use WPA (not WPA2) Shared TKIP with MAC address filtering.

The routers are set for Channel 11, and I force only G (no B) mode.

That's good information, Earl.  We'll see if that helps to reproduce the problem here!

http://forums.slimdevices.com/showpost.php?p=226423&postcount=8 suggested enabling SSID broadcast.

It turns out two of my routers were broadcasting SSID, and the other two were not.

I've got them all broadcasting SSID now. I am using channel 11.

Overnight, one of the wireless SB3s lost connection. Thus broadcast SSID is not a significant factor.

This morning I confirmed the loss by trying to ping the SB3 with no success.

Rebooting that SB3, the connection was regained immediately and I was able to ping the SB3.

Note that my WRT54Gs are configured with WDS + AP mode to get better coverage over my house.

cc'ing our other firmware developer in case he has any ideas as well.

hirschaj writes in http://forums.slimdevices.com/showpost.php?p=227086&postcount=13

> I had the same problem with a dd-wrt flashed router. I ended up using an old non-dd-wrt router
> as an access point for my SB and it does not drop out anymore. Seems like a SB/router firmware bug.

I am not using DD-WRT, although I believe both DD-WRT and Hyperwrt 2.1b1 + Thibor15c, which I run, are based on the Linksys WRT54G Linux firmware.

For what it's worth, I have no issues with WRT54GL v1.0 running Linksys stock firmware 4.30.9 with DHCP and WPA Personal TKIP on G-only network band

Created attachment 2143 [details]
slimserver log file

Here is a log of slimserver activity using d_slimproto and d_source. There is a wireless network outage around 15:23, after which only one SB3 recovers (192.168.1.203 00:04:20:07:52:38) at 15:28.

There is another outage at 15:58 at which point the slimserver reports that it is forgetting about this player.

Interestingly the slimserver doesn't report having to forget about the other SB3 player at 15:28.

OK, not to be side-tracked too much here, I have to point out that this has nothing to do with slimserver at all. At the moment I don't have a slimserver running as I am rebuilding a new server, so SB3 is only working with squeezenetwork. But it keeps happening (twice in the last 3 days). Also my WAP is completely standard, not flashed or anything. At some point I borrowed a netgear just to try and got the same problem. So nothing to do with the WAP nor the slimserver. It is the SB3 firmware that for some reason does not want to reconnect automatically, but as pointed out here it has no problem reconnecting by holding the power button down.

Now, if I was a slimdevices employee ( ;-) ), what I would do, to get to the bottom of this once for all, would be to create a special firmware version with some logging capabilities and ask one of the many people here willing to help to keep it running in order to capture what happens on the SB3 and not on the slimserver since it has nothiong to do with it. Even better I would send a modified version of an SB3 so that we didn't have to screw up our own SB3 :-)

Just as suggestion (at least that was what I used to so in my previous company when I had firmware problems to debug).

The lack of apparent progress is frustrating.

I was unable to get anything useful out of WireShark because my wifi card won't snoop.

I've switched my WRT54G firmware to OpenWRT to see if the fault continues.
Assuming it does, I hope that I can use information from:

http://mobilesociety.typepad.com/mobile_life/2007/01/wifi_network_tr.html

to get some information from WireShark.

I also see there's a 82 firmware build in the SlimServer 7 overnight builds.
It might be more fruitful to see if the problem exists there.

I've switched all my firmware to OpenWRT White Russian 0.9.

I found that I had to set:

% nvram set wl0_afterburner=off
% nvram commit
% reboot

With the afterburner set at auto, I'd get frequency dropouts.

I've also set the antenna selection to diversity mode:

% nvram set wl0_antdiv=3
% nvram commit
% reboot

I did see an "encryption failure" message last night on each
of the Squeezeboxes, but I'm waiting for the configuration to
stabilise before I attempt to do much more debugging.

I plan to install SlimServer 7 next.

(In reply to comment #25)
> I plan to install SlimServer 7 next.

I installed SS7 with firmware 82. The situation now is vastly improved. The one SB3 that is furthest
away (connection strength 30% or lower) still has outages but can recover on its own --- it still
can take up to 30 mins for it to recover the link but during the quieter parts of the day (evening)
it seems to be able to retain the connection.  The other wireless SB3 is closer to the router and
has a connection strength of about 50% or lower and only loses connections intermittently and can
recover very quickly.

I an using OpenWRT 0.9 WhiteRussian with the settings as before. I have also taken the trouble
to continuously synchronise all the clocks on the WRT54G routers using ntpclient.

Chris, is it possible that the new firmware available in the nightly builds addresses some of the issues in this bug?  Perhaps we can take a look once 'Sniffy' is back up and running.

It appears that this bug has been resolved.  Re-open if it's still an issue for you.

(assigning to steven to reproduce if it returns)

(In reply to comment #28)
> It appears that this bug has been resolved.  Re-open if it's still an issue for
> you.
> (assigning to steven to reproduce if it returns)

So what was done to fix it? Is there a new firmware I need to download or what?

Thanks.

Yes, please.  Update to the latest pre-release version of SqueezeCenter from here:

http://www.slimdevices.com/downloads/nightly/latest/7.0/

You will be offered the new firmware automatically.

If you are still seeing this issue with the new firmware, please reopen the bug.

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html