Two Possible Work Arounds for Connection Timeout Issue With New Firmware

monoskier · September 14, 2011, 10:09pm

I disabled Mionet at startup and then competely repowered down the actual network - modem, router, drive . After the restart, I put all the computers to sleep and went out for a half hour. Came back and it connected without the usualy headaches!

Note: It’s been about an hour now that has included 30+ minutes of all computers at least in stand by mode and a full reboots on the MPB with immediate reconnections. I’m won’t be fully convinced of my solution working untilleaving everything off overnight and sucessfully connecting without issue in the morning.

UPDATE: Been about 3 hours and all is normal. Most of this time has been with the cpus sleeping and the drive reconnects when needed.

UPDATE 2: Had the drive and cpus inactive form 6-11. Turned the MPB back on and it cant find the drive so my solution doesnt work for long periods. Can’t speak for Brownster’s solution below…

or

From Brownster:

First make sure you can login to the admin pages of the NAS. To do this, I unplugged the ethernet for 10 minutes or so. Then I plugged it back in and power cycled (power cable out for 10 seconds then back in). After a couple of minutes I saw the drive in Finder and then logged in via Bonjour (default uid and pwd are both admin).

Clicked on Advanced Mode
Clicked on the Network tab
Clicked on Services
Unticked the AFP Service checkbox at the bottom
Clicked submit

Immediately I noticed how much more quickly the menus refreshed and all connectivity seemed a lot more snappy.

Ok, so now I can’t use Time Machine since I have disabled the afp functionality. To access files on my NAS, I simply used an smb connection instead (Finder, Go, Connect To Server, smb://yourdrivename) and had to login as Guest rather than Admin.

I’m quite happy with this temporary fix since I managed to get a full backup in yesterday and I will wait until the AFP setting is fixed before I try again!!!

Hope this works for others. And hope this helps WD Support pinpoint the problem a little better.

_________

If people try either of these please report back on success rates GL!!!

feartheyu · September 15, 2011, 12:03am

I’ll give this a try and post an update. Thanks for sharing!

monoskier · September 15, 2011, 5:19am

solution 1 does not work over long periods. oh well.

Brownster · September 15, 2011, 6:11am

Neither does solution 2 (although when it works it is a speedier connection without AFP),

Guess we’ll just have to wait for the professionals…

timeimp · September 15, 2011, 6:35am

Apparently, disabling TWONKY might help.

Brownster · September 15, 2011, 7:05am

timeimp wrote:

Apparently, disabling TWONKY might help.

For a large part that defeats the purpose of having the drive for me, since I stream movies to my TV using Twonky. Also, it worked fine before, so that can’t be the real fault.

monoskier · September 15, 2011, 7:12am

I saw that mentioned somewhere also. I guess I’m not familiar enough with SSH protocols to know how to disable it without some guidance on that though.

tried “sudo chmod -x /etc/int.d/twonkyserver” (without the quotes obviously) but that didn’t seem to work. It just started back up again when rebooting the drive.

chmod 644 /etc/init.d/S97twonkyserver <----- that apparently stops twonky. I’ll update in the morning if it worked.

UPDATE: I was able to connect in the morning. I was prompted for my password though and that has only happened when I have changed it.

UPDATE 2: Went to get some coffee, can back and the connection failed. For me, it seems disabling TWONKY might have made it worse.

timeimp · September 15, 2011, 10:54am

This is just plain annoying - not bad, not sad or poor product testing on WD’s part, just annoying. WD were nagged by the Mac users to update AND were caught out by Apple. In the mean time, I managed to SSH into the MBMW and found this really interesting: there are around 10-12 instances of ‘twonkymediaserver’ running, all consuming 1.8% RAM. When running a Time Machine backup, the process ‘cvm’ spawns at least 20+ instances of itself and then goes back down to around 15-20 instances.

See the screenshot here.

ssh into the MBMW and run:

top -d 1

and screenshot what you see. Make sure you fullscreen your CLI app to view as many processes as needed. Perhaps a wayward process is to blame?