Bugzilla – Bug 10522
Controller loses logical connection, Linksys WRT610N
Last modified: 2011-03-16 04:34:06 UTC
I have a classic, a duet and a boom. I am currently using a late 7.3.2 release but problem has been around since I got the controller. The controller is nice but almost never works without a restart when I pick it up (it may recover after several minutes if I let it). It always works after a restart. (Although changing players is quite slow with spinning dots for several seconds) The controller is a device which should allow me to put on music or alter volume etc instantly - not taking 2 minutes or similar. The rest of the family gave up on using it long ago and sometimes uses the web interface which is fast (from a PC - but in reality the receiver is mostly quiet and the boom and classic with remotes are used instead. Linksys Wireless-N 610 router with MAC filtering. I wonder if it could be that the controller software tries to connect before the wlan link is properly established and the software waits for a timeout before reconnecting.
I've seen this myself. I think it was a case of losing the wireless connection and not being able to recover. I live in a crowded area for wireless (20 or so show up on my airport networks list). I now have a dual router setup, one Dlink N Extreme and another Linksys N that covers both floors with over 80% signal strength (more than 10% better than any other interfering network). I no longer have this problem. Try experimenting with channels. If you can find a good scanner that looks for neighbouring networks and gives you the channels, you can pick one that isn't being used heavily. Best channels are 1, 6 and 11 as they do not overlap.
The Linksys is set to pick the least used channel automatically and I usually have the controller within 10 feet of it when it happens. In my view the software should be fixed so it doesn't depend on an always present and perfect connection - and the wifi should be able to reconnect as well since it is able after a reboot.
QA to try to reproduce this problem. We've fixed many connectivity issues, and this is no longer a common problem.
Ross: can you look into this?
This sounds a lot like bug 9388. Christian could you please try disabling power management on your Controller and see if this helps?
Settings - Advanced - Factory Test - Power management - Wireless power save, disable this. KDF, are you using the 610N as well? As mentioned in bug 9388 I put it through its paces here in the office, in a fairly busy wireless environment, and wasn't able to reproduce any problems. Maybe I should give it another try now that things have changed a bit with Controller wireless performance. Also Christian, while your router should choose the ideal channel, it may be better for you to make that decision instead. Could you please try using netstumbler or something similar to have a look at the channels most occupied in your area.
Mine is a 160N, the single-band ,non-gigabit version. The DLINK never shows any wireless connections in the house, so the linksys is the clear winner in the selection even when it's a floor away.
Note: Steven and I hammered on the WRT610N with 3 Controllers and 3 Receivers, powering them on and off randomly using timers to try to induce a failure to reconnect. After about 2 months we weren't able to reproduce anything.
Happy to see activity on the matter. I am unfortunately traveling thru the 15th but will try more when I get back home. I actually used to know quite a bit about wlan - wrote 2 different linux wlan drivers and a psion driver in a galaxy far far away... I have a "hunch" (in no way built on facts though...) the controller isn't recovering from lost transmissions on the WLAN layer properly. My router has 802.11 frameburst enabled as per linksys default. Will check power mgmt when I get back. /C
Any progress, Christian?
Christian let us know if you're still experiencing any issues and we'll consider re-opening this bug. For now I'd like to resolve it as it does not appear to be a problem anymore.
Sorry for not responding promptly. The controller update that came shortly after my submission seems to have cleared things up a bit; the controller recovers _better_ (though not as fast as I would prefer - TCP timers should perhaps be interrupted when WLAN coverage is lost?). Testing now clearly shows that there is a queue build up either in TCP or in higher layers. (e.g. if I go into the far reaches of my kitchen (where the wlan coverage border is) listening to random mix and press play/pause/play/pause/.../... and go back into coverage it takes ca 3 seconds (TCP timeout?) and then I see pause - play - pause -... status popups flashing by on controller. My initial reported problem was not directly due to wlan coverage but the controller lost connection even when sitting 10ft away from my WLAN router and only way to recover was power cycle of controller. Now it seems to recover better which is good. /C