Workaround for Disconnect Problem - Works for all my and my dealers clients

Hi,

I got a few complaints about the “MY Cloud Personal” devices I sold and contacted my dealers technical support, they told me that they get many complaints and nobody seems to know why they work for some people and not for others. He told me to send the defective devices back for a swap out…

After speaking with my contact, telling him a change won’t solve the problem and more likely make my clients angrier than they already are, he agreed  to my suggestion and sent me 4 devices, 2 new (2TB) and 2 used (3TB), for testing. I took another 4 (2,3 & 4TB) from my clients and my 2 (4TB), so I had a total of 10 devices which I marked, tested with different routers/switches and the same settings at the same time. All devices were “cleared and factory reset” (except of my “production device” which I used as a control device), had the same (newest) firmware and same settings, even users and shares. Only the names where different MYCLOUD1, MYCLOUD2… It didn’t make any changes if the device was “almost fully loaded” or only had “a few files” or were 2,3 or 4TB.

I personally have 2 My cloud personal devices (4TB). The first one I bought back in feb. 2013 after seeing it working at a new client. The second was bought in dec. 2013. Both devices are working “fine” straight from beginning. The only problem I had was “power save” seems not to work right - and since a few months I noticed the drive spins up every now and then.

One device is used for my business as a storage and backup device the other one is used to serve music, photos and videos mostly to my home devices via WiFi. I notice a short delay (device in sleep mode, drive has to spin up etc…) when I access the device thru my TV when playing a video or music… This is normal and acceptable but since the last update I have the feeling it takes a bit longer…

I recommend these devices to many clients and have sold around 15 My Cloud Personal devices during the past 8 months. 6 devices have the same problem as most of you: periodical disconnect, not reachable, need to pull power jack… drive spin up.

My clients and I don’t see the “drive spin up” as an error or big problem so I left that out and only did some testing with different routers (Linksys, speedsport, netgear, avm fritzbox, d-link; those that are most common here) and also attached them direct to different switches (3com, HP, Netgear, 100 and 1000) to see if the disconnect problem can be reproduced, localized.

Well normally you should think that all devices would act the same e.g. 4 devices with the disconnect problem would also disconnect when attached to the same router or switch - BIG SURPRISE THEY DIDNT!

This is what/how I tested:

Test scenario 1:
3 devices with DHCP on the same router (running 3 tests at the same time on routers: Netgear, AVM, Speedsport)

Disconnect times varies between 3-30 hours. The Devices disconnected “at their own will”. Device 1 disconnected somewhere after 2-4 hours, device 3 somewhere after 24-30 hours. During the second test device 1 disconnected after 8-10 hours and device 2 after 24-30 hours.

From my stand I think the variation time could be a matter of how the routers handle power save and ip leases. The drive falls into “sleep mode” and then seems not to recognize the “wake-up” signal.
Funny: there is NO drive spin up?!?!

His test was repeated with disabled power saving the disconnect came between 2-6 days.

Test scenario 2:

3 devices with DHCP on the same switch (running 3 tests at the same time on switch: 3com, Netgear, HP)

Same problems here. Disconnection times varies between 2-30 hours. None of the devices disconnected during the second test at the same time.
The drive falls into “sleep mode” and then seems not to recognize the “wake-up” signal.
Funny: here is also NO drive spin up?!?!

His test was repeated with disabled power saving the disconnect came between 2-6 days.

Test scenario 3:

3 devices with Static IP (within the DHCP range) on the same router (running 3 tests at the same time on routers: Netgear, AVM, Speedsport)

Frustration pure: Disconnection times varies between 6 hours and 4-6 days. None of the devices disconnected during the second test at the same time.
The drive falls into “sleep mode” and then seems “sometimes” not to recognize the “wake-up” signal.
Funny: also NO drive spin up?!?!

His test was repeated with disabled power saving the disconnect came between 2-6 days.

It looks like the device falls into sleep mode, can be accessed a few time and then falls into “coma” due to the routers IP lease time.

Test scenario 4:

3 devices with Static IP (within the DHCP range) on the same switch (running 3 tests at the same time on switch: 3com, Netgear, HP)

Same here, disconnection times varies between 6 hours and 4-6 days. None of the devices disconnected during the second test at the same time.
The drive falls into “sleep mode” and then “sometimes” seems not to recognize the “wake-up” signal.

Funny: again NO drive spin up?!?!

His test was repeated with disabled power saving the disconnect came between 2-6 days.

It looks like a problem with the IP lease time, after the device falls into sleep mode the lease is given up and marked inactive when a request is started the device doesn’t react e.g. the router seems not to be able to “find” the device.

Test scenario 5:

3 devices with Static IP (out of the DHCP range) on the same router (running 3 tests at the same time on routers: Netgear, AVM, Speedsport)

This test made me happy: Drives fall into “sleep mode” like expected, times varies but it doesn’t matter.
The drive falls into “sleep mode” and recognize the “wake-up” signal even from “outside” via tablet or handy.

Funny: the drive spins up every “now and then”?!?!

His test was NOT repeated with disabled power saving!

Test scenario 6:

3 devices with Static IP (out of the DHCP range) on the same switch (running 3 tests at the same time on switch: 3com, Netgear, HP)

Same here, Drives fall into “sleep mode” like expected, times still varies but it doesn’t matter.
The drive falls into “sleep mode” and recognize the “wake-up” signal even from “outside” via tablet or handy.

Funny: the drive spins up every “now and then”?!?!

His test was NOT repeated with disabled power saving!

My personal conclusion:

Fact is, all devices with DHCP or Static IP within the DHCP range and with/without power saving disconnected somewhere between 2 hours and 4-6 days, on the other hand all devices with a static IP outside the DHCP range don’t seem to have the disconnect problem even if power save mode is enabled… The only way to bring the disconnected devices back was to pull the power jack!

After checking the clients who bought the My Cloud devices and had problems I found out that all that had problems didn’t want a pre-configuration and used DHCP or static IPs within the DHCP range.

When I setup a Router/Network and install devices I always set my DCHP range low somewhere between .5 to .190 and only give double, max triple IPs as needed for PC, Notebook, Handy, Tablet etc… All other devices like printer, server, tv-boxes etc. get a higher range .200 .240 static IP far out of the DHCP range → which I also did for those clients who wanted a pre-configured device or where I installed the device myself.

After testing all this and finding out that a static ip outside the dhcp range solved the disconnect issues…

my tip would be switch to a static IP OUT OF THE DHCP IP RANGE.
And always manually update, after updating I always shutdown the device via web-interface, disconnect it from power, wait a few min and plug it back in.

Thru my business I had contact to over 100 people using the my cloud personal device with many kinds of routers and environments. Most of them solved the problems by changing the IP.
Some Fritz box users still had problems which were solved after setting their ports from “green mode” to “power mode”.

However, some questions are still open.
- Why does the drive periodically spin up?
    (this could be a sneaky way to solve the wake-up problem!? If so then…)
- Why doesn’t the drive periodically spin up when using DHCP?
- Why doesn’t the device recognize the “wake-up” signal e.g. request when it’s in sleep-mode using DHCP?

After installing the 3.04.01
- Why is the video loading time so long?
    (or is this just a “feeling”, cant test because I can’t downgrade the firmware. Downloaded and renamed old firmware to newer version but didn’t work get an “improper Firmware 370001” error.)
    

My thoughts to the disconnect problem:

I have 5(china) ARM devices, all run with linux which I use for testing (mail-, dhcp-, web-, tracking-, Cloud-server). They also had disconnect problems e.g. when they fall into sleep mode they disconnect, the only way to bring them back was to manually wake them up via power switch or pulling the power jack.

From experience I know that there was (long, long ago) some network cards that couldn’t handle power saving, you had to update the drivers and disable power saving in driver settings or disable power saving complete.
So this was my starting point, after 3 months of testing and patching I was able to also wake them up via usb or bluetooth keyboard and finally also solved the disconnect problems = it was the sleep mode settings.

In sleep mode the type of power saving for everything was “completely turned off” and as long as the device itself was in sleep mode it didn’t recognize any sort of keyboard or network activity → how cold it everything was turned off except the power button, devices without a power button need to be unplugged! This sounds quit similar to what the My Cloud Personal does…

This sort of power save mode is logical for a single device like a tablet but illogical for a device used as a server.
The simple solution was to edit the power save settings and tune/disable the usb/bluetooth and network adapters sleep mode. Since june last year the ARM devices work perfectly data is served even if the device falls into sleep mode.

The big question here is:
If it’s a power save setting
- Why does the device work with a static ip and not with dhcp?
If the drive spin up is used as a workaround
- Why doesn’t the device spin up the drive in dhcp mode?

Could it be, that there are different power save modes integrated which conflict or that one disables the network card completely?

Well, maybe one of the programmers could take a look into this…

I hope this helps some of you and helps finding out what causes the disconnect issue.

Hop this doesnt sound like  I am a “Smart A@@” trying to teach you, so no offense meant to anyone.

Greetings from Germany
Bob

10 Likes

Thanks Bob.  

  1. In Test Scenario 6 you probably meant to say “Out of DHCP Range” instead of “Within”.

  2. What procedure did you use to detect a disconnected Cloud? 

  3. You mentioned not being able to revert to a previous firmware.  I recently posted a solution for that.  SSH to the MyCloud and edit the “etc\version” file to a previous (lower) number than the FW you want to install.

FYI, I have never had the disconnect problem in eaither of my Clouds (2TB and 3TB).  I use a router-assigned IP based on the Cloud MAC.  The IP is outside of the router DHCP range.  I have also used a static IP with no assignment from my router and that works fine too but don’t like that solution because if you have to reset your Cloud device (I did recently) then when the drive comes back up the user-defined MyCloud network settings are wiped and the Cloud gets an IP from the DHCP pool.  Then you have to do some digging to find out what it is and then change.  So I went back to the IP address assigned by the router based on MAC address which will be outside of the router DHCP pool.

@SlimyPizza

  1. changed it - Thanks

  2. Did that what my “average Joe” clients would do:

Wait, then Try TV, App, PC, Web UI, Ping and then give up and pull the chord  :wink:

For testing I simply made a few scripts which sporadically tried to access the devices → take a file, rename and copy it. The time trigger was set to min. 1 and max 4 hours. So I cant exactly say when the device “slipped away” or if the time varies are part of the trigger time. That didnt really bother me, I just wanted to know if and how the devices disconnect and reconnect.

I can see in the log, that the devices were accessible (e.g. at 8.24pm) and then gone (e.g. at 10.05pm)

  1. Saw that Guide too late, found one just saying "get the old FW rename the file to newer name and update…

The problem with SSH: how can you give that info some “average Joe” who is 100 miles away? Knowing he WILL kill his device even if you guide him on skype…

It would be better you could upgrade/downgrade without all that… just add a “downgrade” button and 1-2 questions e.g. You want to down grade your FW? → OK → Are you sure? → OK-> Really? → DO it

“I use a router-assigned IP based on the Cloud MAC.”

Thats good - But some ( I would say most) routers are limited and you cant do that. So self assigning a static IP is the best way.

What I do when I sell a device is ask a few questions (gather ip information) and then always add a sticker with the information: buy date, IP stuff, urls, tele.nr…

So the clients know the IP Stuff, if they cant handle it / doesnt work: where to call, I know guarantee and IP stuff and can guide them thru setup…

After much frustration with MyCloud becoming inaccessible after a few hours, half a day at most, and needing a power reset to recover, I followed your advice and:

  • set MyCloud to a static IP out of DHCP range
  • set Energy Saver Drive Sleep to off

Result is problem solved. Since making those simple changes drive has remained available for days: Many thanks for your research and suggestion

Greenspangle wrote:

After much frustration with MyCloud becoming inaccessible after a few hours, half a day at most, and needing a power reset to recover, I followed your advice and:

 

  • set MyCloud to a static IP out of DHCP range
  • set Energy Saver Drive Sleep to off

 

Result is problem solved. Since making those simple changes drive has remained available for days: Many thanks for your research and suggestion

From analyzing the firmware it could be that this helps in many cases.

Imho it is not the real solution of the problem.

Greenspangle wrote:

After much frustration with MyCloud becoming inaccessible after a few hours, half a day at most, and needing a power reset to recover, I followed your advice and:

 

  • set MyCloud to a static IP out of DHCP range
  • set Energy Saver Drive Sleep to off

 

Result is problem solved. Since making those simple changes drive has remained available for days: Many thanks for your research and suggestion

 I suggest turning Energy Saver back on and see if that hurts. I suspect the IP change is what helped.

@ All,

I find this all bizarre.

I do not have any My Cloud Disconnects. It’s been working 35 days without any disconnects.

Mine sleeps, Mine Scans, Mine Copies, from few files to large heaps of files and big files and makes Safepoints at night.

BUT WHAT NOBODY SEEMS TO BE WILLING TO DO of what I have said over and over again.

SET YOUR MYCLOUD TO DHCP and YOUR ROUTER IP RESERVATION in THE DHCP RANGE and try to choose a high upperlevel IP address in the DHCP POOL and force the MY CLOUD to choose that IP address again and again because of 1 day lease. 

 

SO for example IP ADDRESS POOL 192.168.1.100 then make 50 IP Addresses so that is 192.168.1.100 to 192.168.1.150.  Then put the My Cloud on for example 192.168.1.146, or 192.168.1.147, 192.168.1.148, 192.168.1.149  be putting any of those addresses PERMANENT in the DHCP RESERVATION. 

 

Best thing is to put all of your hardware like that. Except a Mananged SWITCH.

 

I hope someone will listen to me NOW !

 

THAT IS IF YOUR ROUTER CAN DO THIS, DO DHCP IP RESERVATION !!!

 

Why not try ? Nobody listens to me.

 

And for heavens sake gimme me kudo’s for that.

2 Likes

Pacific_Dollars wrote:

@ All,

 

I find this all bizarre.

 

I do not have any My Cloud Disconnects. It’s been working 35 days without any disconnects.

 

Mine sleeps, Mine Scans, Mine Copies, from few files to large heaps of files and big files and makes Safepoints at night.

 

BUT WHAT NOBODY SEEMS TO BE WILLING TO DO of what I have said over and over again.

 

[…]

Why not try ? Nobody listens to me.

 

And for heavens sake gimme me kudo’s for that.

Many issues in this forum are bizarre. Some MyClouds of privileged persons work at highes speeds like a charn, do their sleeping, never loose connection, have low head load counts etc etc.

Others of less priviledged owners behave differently, often very volatile or even nasty.

Your solution may help in some cases, but in others most probably not.

Loss of connection is intertwined and difficult to debug.

Anyhow, gave you some kudos :smiley:

@ Count Dooku,

How can it not work ? This is working for over 10 years like that. I did not have a My Cloud for 10 years. But DHCP Reservation works. Unless you have a hardware fault.

1 Like

After getting many PMs:

My Post describes what I did to find a work-a-round for the disconnection problem my and many of my dealers customers in germany had.

I am quite sure there are also other solutions. The problems seem to come with a constellation of router, settings, configuration, usage and a bug in the firmware. Else it is not understandable why the drive works for some and not for others right out of the box or why it works with a statc ip and not with dhcp.

“…this is not a real solution…”

Of course its not the “real” solution but its a working work-a-round. A “real” solution would be when a firmware update comes out where the problem is solved.

However, I am realist and know that could take years and before I tear out my hair everytime someone calls me with that problem, I simply tell him this work-a-round. Takes 2-3 mins and He is happy it works.

“…SET YOUR MYCLOUD TO DHCP and YOUR ROUTER IP RESERVATION…”

First, yes that would work to.

BUT, and thats why I didnt talk about it, most routers here are straight from the providers “limited” in there configuration. So that wont work straight out of the box. You need to flash the router with the original firmware and if something goes wrong… But whats not limited is setting a static ip and thats described for every router from ervery provider and manufacturer - yes even from WD :wink:

See, most of the people I deal with are “average joes”, people who can write emails, use twitter and facebook but bearly know why they need a router or how to set an IP - I think thats why DHCP was “invented” in the first place :wink:

“…Many issues in this forum are bizarre…”

Yep, thats true.

I had 10 drives all acting different and still I could not reproduce some of the issues that were talked about here. Like I said above its a constellation of different things and no manufacturer can test every possible constellation.

2 Likes

I’ve bought this device almost 1 month ago.

It’s configured using DHCP to assigned static ip (from pfSense firewall by mac address ).

It keep on disconnecting.

Today I’ve disabled the power setting if the problem will persist i will try to configure static ip

Thefix wrote:

I’ve bought this device almost 1 month ago.

It’s configured using DHCP to assigned static ip (from pfSense firewall by mac address ).

It keep on disconnecting.

Today I’ve disabled the power setting if the problem will persist i will try to configure static ip

Click on the envelope at the top right corner to see your private mails in this forum :wink:

I read your pm… ;( but I cannot use that solution (not my fault)

It keep on crashing.

I’ve putted static ip and keep on crashing even in this way.

Network shares became unavailable after few time and also the web interface in unreachable.

I’m very disappointed with this product

I forgot… it keeps reply to pings…

Thefix wrote:

I read your pm… ;( but I cannot use that solution (not my fault)

 

It keep on crashing.

I’ve putted static ip and keep on crashing even in this way.

 

Network shares became unavailable after few time and also the web interface in unreachable.

 

I’m very disappointed with this product

 

I forgot… it keeps reply to pings…

 

Sorry, I am too silly to understand your situation :frowning: