Bugzilla – Bug 7153
Poor connectivity with ZyXEL routers
Last modified: 2009-06-03 09:45:58 UTC
This is a bug for the issue described at http://forums.slimdevices.com/showthread.php?t=43243 . 1. Start in a good state with controller and player working. 2. Power down/power up the controller. 3. The controller is now unusable - see below. 4. Find the IP address of the controller and ping it. I see it either not respond at all, or respond to every fourth packet. 5. Put the player into configuration mode, and use the controller to configure it (Settings->Advanced->Set Up Receiver). Let the configuration process go through. 6. The controller now works perfectly again, just like we started with. 7. Ping the IP address once more - you should now see 100% response. After step 2 the controller may not connect to the server at all; if it does it shows a number of symptoms all related to poor connectivity: not showing player status updates, and failing to retrieve artwork or album/artist lists. Controlling the player seems okay (though it doesn't always reflect the changed player status) Responding to every fourth ping packet is curious; for example (note the icmp_seq numbers): ==== $ ping 192.168.1.38 PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data. 64 bytes from 192.168.1.38: icmp_seq=4 ttl=64 time=3.85 ms 64 bytes from 192.168.1.38: icmp_seq=8 ttl=64 time=9.71 ms 64 bytes from 192.168.1.38: icmp_seq=12 ttl=64 time=6.84 ms 64 bytes from 192.168.1.38: icmp_seq=16 ttl=64 time=9.28 ms 64 bytes from 192.168.1.38: icmp_seq=35 ttl=64 time=9.44 ms 64 bytes from 192.168.1.38: icmp_seq=39 ttl=64 time=7.99 ms 64 bytes from 192.168.1.38: icmp_seq=43 ttl=64 time=6.53 ms 64 bytes from 192.168.1.38: icmp_seq=47 ttl=64 time=6.98 ms 64 bytes from 192.168.1.38: icmp_seq=51 ttl=64 time=5.02 ms 64 bytes from 192.168.1.38: icmp_seq=55 ttl=64 time=5.90 ms 64 bytes from 192.168.1.38: icmp_seq=59 ttl=64 time=6.40 ms --- 192.168.1.38 ping statistics --- 61 packets transmitted, 11 received, 81% packet loss, time 60011ms rtt min/avg/max/mdev = 3.859/7.090/9.714/1.784 ms ==== It's as if the wireless isn't starting up properly on power up; but when it switches to an ad-hoc network (for configuration) and back again it resets itself. I've confirmed this behaviour today with builds SC 17533 and SBC r1946, but I suspect I've had this issue for some time. I get exactly the same behaviour with both the older and newer controller beta units you have provided. Network configuration: Router is a Zyxel Prestige 660HW-61 at firmware V3.40(PE.11) with 128-bit WEP. The server is running on an Ubuntu Gutsy PC. SBR connects wirelessly (and works perfectly). The server is wired to the router, but uses DHCP. The SBR and SBCs are in the same room as the router with clear line of sight. My network also has another (wired, static IP) PC running SlimServer 6.5.4 on Ubuntu Feisty serving two SqueezeBox 3's wirelessly, all of which work well. I am using wireless channel 4. Other networks around are on channels 11 (20% strength), 1 and 13 (<10% strength). Thanks, Ian
Thanks for the excellent report, Ian... QA folk: please try to reproduce this ASAP.
ZyXEL Prestige 660HW ordered and on its way.
Probably unrelated, but just in case it helps, I've just tried the md5 test described by Dean at http://forums.slimdevices.com/showthread.php?t=43517 and had no problems with the controller in its "good" state. With the controller in its "bad" state I can't get a SSH session at all.
Hi, I've recently experienced other problems with the Zyxel router, so I've today replaced it with a NetGear DG834PN. As expected, I no longer get poor usability after restarting the controller. However - pinging the controller suggests that there is still a networking issue after reboot, which is somehow fixed while setting up a receiver. After a reboot, I get: === $ ping 192.168.1.8 PING 192.168.1.8 (192.168.1.8) 56(84) bytes of data. 64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=102 ms 64 bytes from 192.168.1.8: icmp_seq=2 ttl=64 time=229 ms 64 bytes from 192.168.1.8: icmp_seq=3 ttl=64 time=360 ms 64 bytes from 192.168.1.8: icmp_seq=4 ttl=64 time=482 ms 64 bytes from 192.168.1.8: icmp_seq=5 ttl=64 time=96.8 ms 64 bytes from 192.168.1.8: icmp_seq=7 ttl=64 time=250 ms 64 bytes from 192.168.1.8: icmp_seq=8 ttl=64 time=373 ms 64 bytes from 192.168.1.8: icmp_seq=9 ttl=64 time=90.6 ms 64 bytes from 192.168.1.8: icmp_seq=10 ttl=64 time=216 ms 64 bytes from 192.168.1.8: icmp_seq=11 ttl=64 time=345 ms 64 bytes from 192.168.1.8: icmp_seq=12 ttl=64 time=469 ms 64 bytes from 192.168.1.8: icmp_seq=13 ttl=64 time=84.0 ms 64 bytes from 192.168.1.8: icmp_seq=14 ttl=64 time=210 ms 64 bytes from 192.168.1.8: icmp_seq=15 ttl=64 time=336 ms --- 192.168.1.8 ping statistics --- 15 packets transmitted, 14 received, 6% packet loss, time 13999ms rtt min/avg/max/mdev = 84.043/260.770/482.521/132.535 ms === Notice the response times are quite high, up to 500ms. Also: pings 1, 5, 9 and 13 are quicker than the others - this matches the "every fourth ping" symptom I saw with the Zyxel router. After going through the "set up receiver" process, ping response times are dramatically reduced: === $ ping 192.168.1.8 PING 192.168.1.8 (192.168.1.8) 56(84) bytes of data. 64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=3.82 ms 64 bytes from 192.168.1.8: icmp_seq=2 ttl=64 time=4.65 ms 64 bytes from 192.168.1.8: icmp_seq=3 ttl=64 time=3.95 ms 64 bytes from 192.168.1.8: icmp_seq=4 ttl=64 time=4.31 ms 64 bytes from 192.168.1.8: icmp_seq=5 ttl=64 time=4.54 ms 64 bytes from 192.168.1.8: icmp_seq=6 ttl=64 time=4.26 ms 64 bytes from 192.168.1.8: icmp_seq=7 ttl=64 time=4.56 ms 64 bytes from 192.168.1.8: icmp_seq=8 ttl=64 time=4.59 ms 64 bytes from 192.168.1.8: icmp_seq=9 ttl=64 time=4.51 ms 64 bytes from 192.168.1.8: icmp_seq=10 ttl=64 time=3.87 ms --- 192.168.1.8 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9002ms rtt min/avg/max/mdev = 3.820/4.310/4.651/0.311 ms === Perhaps this is observable with other routers too? This is with SBC software r2013. The NetGear DG834PN is running 802.11g with WPA-PSK and is at firmware V1.03.35. I still have the Zyxel router available if you'd like me to try anything with it. Cheers, Ian
The every 4th ping comment reminds me of the issue Dean is seeing in bug 7196, could there be a relation?
Could well be related to 7196. As in that bug, "iwconfig eth0 power off" makes the problem go away (and it comes back again with power on). See: === 64 bytes from 192.168.1.8: icmp_seq=33 ttl=64 time=5.22 ms 64 bytes from 192.168.1.8: icmp_seq=34 ttl=64 time=65.8 ms 64 bytes from 192.168.1.8: icmp_seq=35 ttl=64 time=196 ms 64 bytes from 192.168.1.8: icmp_seq=36 ttl=64 time=425 ms 64 bytes from 192.168.1.8: icmp_seq=37 ttl=64 time=36.8 ms 64 bytes from 192.168.1.8: icmp_seq=38 ttl=64 time=166 ms 64 bytes from 192.168.1.8: icmp_seq=39 ttl=64 time=289 ms 64 bytes from 192.168.1.8: icmp_seq=40 ttl=64 time=416 ms 64 bytes from 192.168.1.8: icmp_seq=41 ttl=64 time=31.8 ms 64 bytes from 192.168.1.8: icmp_seq=42 ttl=64 time=6.80 ms 64 bytes from 192.168.1.8: icmp_seq=43 ttl=64 time=6.81 ms 64 bytes from 192.168.1.8: icmp_seq=44 ttl=64 time=6.07 ms 64 bytes from 192.168.1.8: icmp_seq=45 ttl=64 time=6.12 ms 64 bytes from 192.168.1.8: icmp_seq=46 ttl=64 time=6.72 ms 64 bytes from 192.168.1.8: icmp_seq=47 ttl=64 time=4.03 ms 64 bytes from 192.168.1.8: icmp_seq=48 ttl=64 time=6.81 ms 64 bytes from 192.168.1.8: icmp_seq=49 ttl=64 time=6.00 ms 64 bytes from 192.168.1.8: icmp_seq=50 ttl=64 time=6.03 ms 64 bytes from 192.168.1.8: icmp_seq=51 ttl=64 time=6.68 ms 64 bytes from 192.168.1.8: icmp_seq=52 ttl=64 time=3.58 ms 64 bytes from 192.168.1.8: icmp_seq=53 ttl=64 time=6.55 ms 64 bytes from 192.168.1.8: icmp_seq=54 ttl=64 time=342 ms 64 bytes from 192.168.1.8: icmp_seq=55 ttl=64 time=472 ms 64 bytes from 192.168.1.8: icmp_seq=56 ttl=64 time=83.9 ms 64 bytes from 192.168.1.8: icmp_seq=57 ttl=64 time=211 ms 64 bytes from 192.168.1.8: icmp_seq=58 ttl=64 time=338 ms 64 bytes from 192.168.1.8: icmp_seq=59 ttl=64 time=466 ms 64 bytes from 192.168.1.8: icmp_seq=60 ttl=64 time=81.3 ms 64 bytes from 192.168.1.8: icmp_seq=61 ttl=64 time=210 ms 64 bytes from 192.168.1.8: icmp_seq=62 ttl=64 time=336 ms 64 bytes from 192.168.1.8: icmp_seq=63 ttl=64 time=461 ms 64 bytes from 192.168.1.8: icmp_seq=64 ttl=64 time=75.2 ms === Around ping 41 I did "iwconfig eth0 power off" and around ping 54 I put power management back on - the difference is dramatic! Note that this is with the controller undocked; in bug 7196 I think it is docked. Incidentally, I see these degraded ping response times after the controller has woken up, as well as after it has been rebooted.
Created attachment 3117 [details] pings with and without power management I'm noticing quite a bit of packet loss with the Zyxel, slower but no packet loss with a D-link router.
Richard let me know if there is anything else I can do to help.
In jive 7.0.1 r2149 the wlan power save mode is turned off while the device is active or docked. Does this help, it should be available in tomorrow's nightly builds?
Ross, can you make a packet capture of the pings with the ZyXEL router using sniffy. It would be really good to have a wireless capture, and also a capture on the server at the same time for comparison. Thanks.
Created attachment 3190 [details] sniffy capture pinging jive with power management off, then enabling it.
Created attachment 3191 [details] ping output As soon as I enabled power management the pings stopped returning.
There are too much lost packets in the wireless trace to make any useful conclusions. I have ordered the ZyXEL router of the uk office, and will look at this again next week when it arrives.
In 7.0.1 r2170 I have added an option to disable wlan power save in Settings > Advanced Settings > Factory Test > Power Management. This can be used for testing, and as in workaround while further investigations into this problem are done. Please note that disabling wlan power save will reduce the battery life.
This sound alot like the issue I am having, although mine is a ZyXEL P-2602HW-D1A.. My setup is just like the reporters * both remote and reciever are connected wireless * homebuilt server wired but with DHCP (and ip adress reserved in the router) * setup works fine but it soon degrades with the remote loosing connectivity. * Reciever keeps on playing with no audio problems (all flac) * My server only reports 1-2 % CPU usage My main symtoms are * loaidng of album art is unstable * remote many times hang when trying to browse music library when selecting music library -> artist or music library -> album. Home button and play control buttons react but wheel is dead and the artist/album list never loads. 5 minutes later when I try again it might work or it might not... Is there anything I can do to help you debug this ?
I have tried the "iwconfig eth0 power off" and so far it has solved it for me too. - Album art loads much quicker and not least lot more stable - browsing the music library no longer hangs the remote - the lag (connection issues) when picking up the remote is gone. As a user I would say the main problem is that there are no obvious problems with the wireless network[*] plus other devices have no problems, so the duet remote must be at fault. Depending on how much it hurts battery performance please consider making the "iwconfig power off" the default. [*] - Router showed both devices connected - remote showed full signal health - using squeezecenter the reciever signal strength to 65-70+ (should be good enough) - reciever had no problem streaming - the machine with squeezecenter was not overloaded less than 10% cpu usage
I have been testing with a ZyXEL P660HWP today, with firmware version V3.40(AZB.0). This seems to be working fine for me so far, I will continue using this router for a few days. Ross, can you retest with the SC 7.0.1 and Controller firmware >= 2178. I am not worried about the variable ping times, but we need to check if the Controller works reliably with this router. Ian, if you still have your ZyXEL router and could test with the latest pre-release SC and Controller firmware that would be great. Henrik, if you upgrade to the latest 7.0.1 pre-release SC and Controller firmware you will find an option in Advanced Settigns > Factory Test > Power Management to disable the Wireless Power Saving. This should at least be a work around in the short term. Ross, do you have a ZyXEL P-2602HW-D1A. There appear to be more reports of problems with this router in this thread http://forums.slimdevices.com/showthread.php?t=45031. If you don't have one I'll order one of these routers for the UK office. After testing the P660HP please reassign this bug to me.
Ross to repro with his router.
Richard the only Zyxel we have here in Mountain View is 660HW-61. With r2182 it seems to work very well. Pings don't always reply and SSH access is difficult and slow, but the functionality looks fine.
Hi, Using current 7.0.1 (SC 18680, SBC r2187) and my Zyxel P660-HW, it looks like it works. Remote is responsive and pings are consistent - nice job! Thanks Ian
Richard says he's ordered one of the problem routers at his site in the UK
I am the owner of a SB Duet and Zyxel Router and can reproduce the bug regarding no reconnection after power off of controller or receiver. HW Setup: 1) Router Model Number: P-2602HW-D1A ZyNOS Firmware Version: V3.40(AOM.0) | 08/16/2006 DSL Firmware Version: TI AR7 06.00.04.00 2) Type: Squeezebox Controller Player Firmware Version: 7.0 r2097 3) Type: Squeezebox Receiver Player Firmware Version: 22 If more details needed I am glad to assist.
Well I now have a ZyXEL P-2602HWL-D1A router (firmware version V3.40(AUI.0) | 05/16/2007) and it appears to work perfectly. It does not appear that older firmware versions are available to download from the ZyXEL site, but I note in the release notes with the latest firmware that the WLAN APDK was upgraded in a version released on 12/14/2006. It is possible that the bug is only with older firmware in the ZyXEL routers. Ricky: please download and try the latest beta 7.0.1 SqueezeCenter build. Once installed this will include a Controller update. The beta release includes fixes for a number of other connectivity bugs. I think this will not fix all the problems that you see, so then please try to also upgrade your routers firmware to the latest release from http://www.zyxel.com/web/support_download_list.php. Please do report back if this fixes your problem. I am going to keep this bug open until we have some user feedback (from here or the forums).
1) In Denmark wireless Zyxel Routers are widely used because many danish ISPs provide these routers. But these ISPs do not allow (support) customers to upgrade the router firmware. So I cannot upgrade the firmware. 2) I have upgraded to 7.0.1 r2269 and FW 23. Now the odds are better no longer nil for the SBC to see the SBR upon SC power up. I will try to do some more testing. But overall the wireless lan is NOT robust/stable enough for release. 3) I have run into another problem. It seems that because the SBC did not manage to complete a FW copy from SC 7.0.1. The SBC keeps looping a software update. I have tried a Factory Reset but it seems the SBC still has an incomplete FW somewhere. Please till me how to delete this FW or how to use a SD card. Thanks, Ricky
> 1) In Denmark wireless Zyxel Routers are widely used because many danish ISPs > provide these routers. But these ISPs do not allow (support) customers to > upgrade the router firmware. So I cannot upgrade the firmware. Please contact your ISP and ask them to upgrade the router firmware. > 2) I have upgraded to 7.0.1 r2269 and FW 23. Now the odds are better no longer > nil for the SBC to see the SBR upon SC power up. I will try to do some more > testing. But overall the wireless lan is NOT robust/stable enough for release. The evidence so far strongly suggests that the problem is with the Zyxel router firwmare, and not with the Squeezebox Controller. I now have one report where I user requested that the ISP upgraded the router firmware and early reports suggests that this fixed the connection problems he was seeing. If you continue experiencing problems please include the PID and MAC address of your Controller (these are printed on the label in the battery compartment). > 3) I have run into another problem. It seems that because the SBC did not > manage to complete a FW copy from SC 7.0.1. The SBC keeps looping a software > update. Please see the forums, this is now resolved. You need to download a SqueezeCenter upgrade.
Please let us know if you have remaining problems.
I am still experiencing problems with my controller. Blue icon, failed re-connection etc. I am using Zyxel P-660HW-D1 with latest FW V3.40(AGL.4) | 01/10/2007. My controller is PID LZ807A1, MAC 00:04:20:1A:22:55. Currently running sw 7.0.1 r2287 If I keep the controller charging in the cradle, the connection stays fine, but as soon as I remove it from there and keep it idle for some time, the problems start. I'm beginning to think it could be a hardware / manufacture problem with my particular unit or batch.
I have upgraded to 1) SBC 7.0.1 r2287 and 2) SBR FW 23 3) Zyxel Router P-2602HW-D1A V3.40(AOM.2)_0305 | 03/05/2007 The router is now running with the newest firmware. OBS!!! It is the P-2602HW-D1A and the NOT P-2602HWL-D1A. And yes the controller still systematically goes blue icon even within one meters distance from the WiFi router. Other WiFi hardware connected within 10 meters do not drop out. I will today try a DLink 108G.
I will retest this with the router I have here. I am a little confused why I did not see any issues when I tested it, but you clearly still have a problem. As a workaround on the Controller go to Settings > Advanced > Factory Test > Power Management and disable Wireless Power Save (the box should just be white). I think you will find this works better (but the Controller battery life will be less). Can you let me know your version of SqueezeCenter and the OS you are running it on.
Richard: Here is a extract from the settings|status page: SqueezeCenter InformationSqueezeCenter Version: 7.0.1 - 19177 @ Sat Apr 26 00:20:14 PDT 2008 - Windows XP - EN - cp1252 Server IP address: 192.168.1.33 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt
My Squeezecenter is: SqueezeCenter Version: 7.0.1 - 19177 @ Sat Apr 26 00:26:33 PDT 2008 - Linux - EN - iso-8859-1 Server IP address: 192.168.255.3 Perl Version: 5.8.8 armv5tejl-linux-thread-multi MySQL Version: 5.0.27 Platform Architecture: armv5tejl-linux Hostname: LAGRET Server Port Number: 9001 Total Players Recognized: 1
Retargeting further work on this bug to the next release.
Ross could you follow up with these customers to understand what router hw and fw versions they have so we can try and reproduce these remaining issues?
It looks to me like we're all up to date in terms of firmware: Kungen Zyxel P-660HW-D1 with latest FW V3.40(AGL.4) | 01/10/2007. Ricky Zyxel P-2602HW-D1A V3.40(AOM.2)_0305 | 03/05/2007 Ross ZyXEL 660HW-61 V3.40(PE.11)| 05.22.2006 Richard Zyxel p660HWP V3.40(AZB.0) Still this works for me, however as mentioned pings are dropped and SSH access is very slow.
I have just retested here, and I don't see any lost pings with the ZyXEL router. Ross can you compare using the latest firwmare with wireless power save enabled/disabled, just to be sure that is the issue. It would also be worth comparing with a couple of different Controllers. If we can prove this is the problem then maybe you should ship the router to me for further investigation, as I the router I have here appears to be working fine.
Richard, I'm not able to reproduce this with r2409.
Using the following hardware and software (see HW/SW details) I get the following results: SBC: All power-saving enabled: i: 1a) + 2) + 3a) = non Zyxel combo works ii: 1b) + 2) + 3a) = non Zyxel combo works iii: 1a) + 2) + 3b) = Zyxel combo triggers blue icon iii: 1b) + 2) + 3b) = Zyxel combo triggers blue icon SBC: WiFi power-saving disabled: iv: 1a) + 2) + 3b) = Zyxel combo works with no WiFi power-saving as expected iv: 1b) + 2) + 3b) = Zyxel combo works with no WiFi power-saving as expected Hardware Software details: ////////////////////////// 1a) Music Source SqueezeCenter Version: 7.0.1 - 19251 @ Wed Apr 30 00:20:16 PDT 2008 - Windows XP - EN - cp1252 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Platform Architecture: 586 1b) Music Source Online SqueezeNetwork Service 2) SqueezeBox Type: Squeezebox Controller Player Firmware Version: 7.0.1 r2354 Type: Squeezebox Receiver Player Firmware Version: 23 3a) WiFi - Access Point D-Link DGL-4300 - Wireless 108G Gaming Router 3b) WiFi - Access Point: Zyxel P-2602HW-D1A V3.40(AOM.2)_0305 | 03/05/2007 The router is now running with the newest firmware. OBS!!! It is the P-2602HW-D1A and the NOT P-2602HWL-D1A.
(In reply to comment #35) > I have just retested here, and I don't see any lost pings with the ZyXEL > router. Ross can you compare using the latest firwmare with wireless power save > enabled/disabled, just to be sure that is the issue. It would also be worth > comparing with a couple of different Controllers. > If we can prove this is the problem then maybe you should ship the router to me > for further investigation, as I the router I have here appears to be working > fine. Hi, Richard: what kind of security did You have on the router when You did the test?, the reason I ask is that I have had major connection issues with my ZyXEL p-660Hw-61. And today I found out that part of the problem definately was reauthentication. I'm using WPA-psk and the reauth-timer on the router was set to 3600 sec which matched the pattern in dropouts. My Squeezecenter is running on a Vista Laptop which is also connected wirelessly. I could see systematic errors in windows' system log like eventid : 8033 Browser (master browser stopped) followed by 4201 Tcpip (network adapter connected to the network, and has initiated normal operation). The same errors appear if I switch off/switch on the wireless on the laptop. I tried reducing the reauth-timer to 300 sec. and the dropouts now came every 5 minutes. Pinging during reauthentication looks like this (sorry it's in danish): Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=3ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=12ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Anmodning fik timeout. Svar fra 10.0.0.22: Modtagervært ikke tilgængelig. Svar fra 10.0.0.22: Modtagervært ikke tilgængelig. Svar fra 10.0.0.1: byte=32 tid=8ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 Svar fra 10.0.0.1: byte=32 tid=2ms TTL=254 So I'm pretty sure that at least Vista can't reauthenticate without loosing the connection. Maybee the same goes for Squeezbox reciever and remote?, maybee it's the router wich drops the connection to force a reauthentication. Unfortunately I'm only left with two choices, set the reauth-timer to max 9999 seconds (2h45m) or switch off wireless security completly :-( . I'm testing the system without security now and it seems rock solid. No blue icon on the controller (wireless powersave is on!), no errors in the Vista System log, no dropouts in the music, for the past 5 hours, controller out of cradle. I was hoping to test with WEP-security but I haven't been able to make it work (can't connect Vista to router), so for the time being I'm only using MAC-adress filtering. Hope this can help shed some light on the ZyXEL issues. Cheers Jesper
Now I got WEP 128 bit working and the Duet works perfect, no lost connections any more :-) Seems like WPA-PSK and reauthentication was the problem in my setup. Cheers Jesper
Richard has one of these routers now. Reassigning to him
I tried today with the ZyXEL 660HW-61 router Ross sent me. I could not get the router setup to allow the Controller to connect to my SqueezeCenter. It could access the Internet fine, just not the local network. Any hints? I'll take another look later in the week.
(In reply to comment #41) > I tried today with the ZyXEL 660HW-61 router Ross sent me. I could not get the > router setup to allow the Controller to connect to my SqueezeCenter. It could > access the Internet fine, just not the local network. Any hints? > I'll take another look later in the week. Sounds like You have just experienced one the problems related to the Zyxel routers :-) try restarting the controller and give it some time to connect, then it usually connects to the other two. I have seen this behavior daily, the controller just "couldn't see" SC or Reciever even though they were streaming just fine at the time. It just said "choose" player or I could only choose SqueezeNetwork. One or two restarts usually fixed the problem for a while before i got the blue icon of death. I'm not having these problems any more after switching to WEP 128 bit. I also changed to static IP for the wireless vista laptop running SC, but I think that just helped me overcome some Vista problems with zyXEL and dhcp.
Jesper, thanks that's useful. I'll be trying the router again later in the week and will compare WEP and WPA to see if I get different results. It seems strange that the Controller could not see SC, but could access the Internet. That definitely appears to be a problem with the ZyXEL router, I'll investigate more and see if a work around is possible.
Letton mentions interesting re authentication timer findings.
http://forums.slimdevices.com/showpost.php?p=309475&postcount=243
This won't make the 7.1 release now, moving to 7.2.
punting to 7.3
Hello, Confirming the bugs with ZyXEL 660HW-61 V3.40(PE.11)| 05.22.2006: I've just purchased a Squeezebox Duet and have been setting it up today. I've been experiencing the same problems listed here the whole day, i.e. the remote constanty reconnectes to the server running Squeezecenter and due to this hangs for around 30 to 180 seconds. Once it is back connected it stays that way for about 60 seconds tops... I'm running Squeezecenter 7.2 (linux version, official release downloaded today) on my Qnap TS-209 II. Through the web interface it works perfect. As a workaround I found (from this bugreport) the option to disable Wi-Fi power saving, and after that the reliability improved significantly - no reconnections anymore (for about an hour now). Anyhow, looking forward to having a more stable resolution which would enable a better battery life for the remote.
*** Bug 9699 has been marked as a duplicate of this bug. ***
Moving to 7.3.1
This is just to remind our friends at Slim Devices that we ZyXEL users are still eagerly awaiting a fix. It seems to have been a while since any visible activity on this bug. What a nice holiday present it would be to have this fixed!
Changing target to next release
I have a Zyxel G-5705 wifi AP. It works fine, it just seems that the Controller cannot connect to it as far as a Computer or another device like an ipod touch. For example, my bedroom is about 15meters from the AP (And 2 pretty standard wooden doors not closed all the way usually), and I can use my laptop or ipod touch without any lagging, and even the squeezebox Boom and Classic work pretty ok most of the time. The Controller however keeps on going off and on the network (and the icon shows just one bar for the network when connected). I did also notice that it works a little better when I use the Controller as player, the music usually doesnt stop to rebuffer..
Forgot to mention I use the Controller with SC7.3 stable on Ubuntu 8.04.
I would like to suggest that, instead of promising this fix for the next release, where "next" never comes, Logitech take a different approach: simply send a coupon to all Zyxel users for a $50 rebate from Logitech with proof of purchase of any compatible router. The Duet is wonderful when it works. But short battery life is the least part of this bug. Every time the controller has been off for >24 hr, it requires a series of power-downs and -ups before it will connect properly. Today, after being away for a week, I spent over half an hour fiddling -- rebooting the controller six times and the receiver twice -- before the thing worked. Part of that may have been my reward for changing music source from Squeeze Network to my computer, then shutting off my computer (it was hung by another program) before changing it back. The punishment inflicted on the user (at least this ZyXEL user) by that sequence of operations is really excessive. So, how about it? If a solution is not forthcoming soon -- and it's becoming harder and harder to believe that it might be -- just help us buy compatible hardware. Then, every time we demonstrate your otherwise excellent product to friends, it doesn't look like something terribly broken and difficult to use. Thanks for considering it.
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
Fixed in 7.3.3 - r5225. If you've experienced this bug please update to latest nightly 7.3.3 build. Install the new version of SqueezeCenter, update your Duet firmware, factory reset both Controller and Receiver and setup one more time. Please post here in the bug with your findings. 7.3.3 nightly download here: http://downloads.slimdevices.com/nightly/?ver=7.3
I have been unable to get this fix to work. The update to SC was successful; the program now reports version 7.3.3 - 25903 @ Fri Apr 10 04:07:33 PDT 2009. Firmware update of the receiver was also apparently successful. The Controller will not update, however. In five tries, before and after factory reset, the Controller has downloaded the update but after verifying, reports failure. Suggestions?
After several more tries, the Controller firmware seems to have updated. It displays 7.3 r3993.
(In reply to comment #60) > After several more tries, the Controller firmware seems to have updated. It > displays 7.3 r3993. Mike we're actually asking you to test the beta firmware, it sounds like you're a revision behind. The fixes I think help the ZyXEL connectivity issues are in this version of SqueezeCenter: http://downloads.slimdevices.com/nightly/?ver=7.3
(In reply to comment #61) > > Mike we're actually asking you to test the beta firmware, it sounds like you're > a revision behind. The fixes I think help the ZyXEL connectivity issues are in > this version of SqueezeCenter: > > http://downloads.slimdevices.com/nightly/?ver=7.3 Ross, I'm glad to try it (and I thought I saw some improvement from the last release). I have now installed the latest. SC reports Version: 7.3.3 - 25911 @ Mon Apr 13 03:06:51 PDT 2009. Receiver, version 60 firmware. Controller, 7.3r5225. Need I reset everything? I know how to reset the Controller, but not the Receiver. And of course I would prefer not to reset if not absolutely necessary.
(In reply to comment #62) > Need I reset everything? I know how to reset the Controller, but not the > Receiver. And of course I would prefer not to reset if not absolutely > necessary. If everything is working how you like it, then I'd hate to suggest you make any changes. If you notice any issues please factory reset both Controller and Receiver and run through setup one time. To factory reset Receiver just hold the front button for about 10 seconds, until the light blinks red rapidly.
(In reply to comment #63) > If everything is working how you like it, then I'd hate to suggest you make any > changes. So far, everything works flawlessly. I'll report problems as encountered, or report in a week if I have no problems.
(In reply to comment #64) P.S. It is a real pleasure to have the unit working so smoothly -- I appreciate it.
After a week with the new software, my Duet continues to work with few flaws, and with power saving turned on. This is a huge improvement from previously. I did experience 3 minor issues & don't know if they are related to this bug. These occur after the R has been turned off for a day or so and the C has been sitting in the charger. (I am using my Duet through Squeeze Network to play Internet radio.) (1) Once, on removing the C from its charger, I received "Problem connecting to Squeeze Network." This was resolved by powering the C off and then on again. (2) Another time, "Play" worked fine (playing the last Internet radio station). But when I clicked on "Favorites", the ">" opened and closed repeatedly, but I was never able to access the Favorites or anything else. This, too, was resolved by powering the C off and on. (3) A third time, the C displayed a menu titled "Home" (instead of the player name) and with only two entries: "Settings" and "Music Source." Not being able to get music to play, I powered the C off and on, and this issue was resolved. I hope this report is helpful and that these few remaining oddities -- they seem to occur when the C has been off for > 24 hrs -- can be fixed.
(In reply to comment #66) > > I hope ... that these few remaining oddities -- they > seem to occur when the C has been off for > 24 hrs -- can be fixed. I meant to say: "when the RECEIVER has been off and the CONTROLLER in its cradle for >24 hours".
Thanks for the feedback Mike. I'm going to mark this bug as verified as fixed. There was a clear ZyXel connectivity problem, there isn't any more, this bug is resolved. What you were experiencing could be another bug, or intermittent technical Squeeze Network issues, it's not easy to say. They certainly are not ZyXel specific connectivity issues though, so I think it best to wrap up this bug.
(In reply to comment #68) > Thanks for the feedback Mike. I'm going to mark this bug as verified as fixed. > There was a clear ZyXel connectivity problem, there isn't any more, this bug is > resolved. > > What you were experiencing could be another bug, or intermittent technical > Squeeze Network issues, it's not easy to say. They certainly are not ZyXel > specific connectivity issues though, so I think it best to wrap up this bug. Sounds fine, Ross. If you get any insights into those very intermittent and relatively minor problems, do let me know.