What mechanism is used to access MyCloud Live over the Internet?

About 3MB up and down when at the uni. These are bytes, not bits. At home download bandwidth is 1.8MBps. Upload from uni to home clocked on average 300KB, with numerous, regular peaks followed by 0, all on a single file.

But still doesn’t answer the main question.

Cubytus wrote:

Hello there, 

 

in my quest to make my MyCloud Live accessible through the internet, I’d like to know what is the precise mechanism used by WD’s software to reconnect to it.

I’m not sure what you mean by “reconnect” – Are you saying that yours loses connection and you want to know how it recovers?

Reconnect, as in reconnection. I assume the MyCloud doesn’t lose connection itself, however the computer does when it’s travelling! How does it find its way to the MyCloud back home since there’s no dynamic IP setting?

The dynamic DNS resolution is handled by WD’s servers.

Well I guessed, but it doesn’t answer at all how it is taking place.

I would like to know how NOT to rely upon a US-based server, and more technically, to be able to connect using any machine connected to the Internet.

Cubytus wrote:

Well I guessed, but it doesn’t answer at all how it is taking place.

You’re going to have to be a lot more specific with your questions, then.

Using WD’s apps, you’re going to have to rely on their infrastructure in order for the app to find your drive.   

There’s dozens (if not more) threads already on the subject of just generic file access from outside your home network’s borders.

By the way, what product do you have?   There’s the My Cloud and the My Book Live.  There’s no such thing as a My Cloud Live.   

Oops my bad. It is a MyBook Live. 

Your ISP speed do not sound right, nevertheless, if you are streaming a file from home while at Uni, it will depend on your home UP speed.  I have 5Mpbs uploads and music files and small files are ok. Videos, out of the question.

Now, to copy/paste files it does just fine.

You can use FTP (non-secure), or SSH/SCP/SFTP combine with DDNS.

My ISP has no trouble whatsoever. At home speed is constant. Remotely, I can upload to my Mac without any drop in speed, up to its max of 15Mbps down ant 1Mbps up. Only the MyBook Live shows an oscillating speed. I don’t download from home to the uni, but can test it if helpful.

“There’s dozens (if not more) threads already on the subject of just generic file access from outside your home network’s borders.”

Since there’s no DDNS in the WD MyBook Live, how would I do that, since it’s my first question to begin with? Would you please point me to the relevant topics mentioning auto opening of local ports for remote access, as well as auto-update of external IP?

You can use inadyn for DDNS on the MBL: http://www.inatech.eu/inadyn/

You’ll need an account with some DDNS provider. I’ve used no-ip, but they’ll nag you every month to refresh the (free) account.

Enable SSH for secure remote access/file transfer. http://community.wd.com/t5/My-Book-Live/What-are-the-steps-to-enable-SSH/td-p/324417

However, you will need to open the ports in your router yourself in order to access the MBL from outside your local network.

optional: If you are behind a router that is not under your control, but have access to a Linux machine somewhere on the internet, you can use autossh to forward a connection to that machine instead, and log in to your MBL via that remote Linux server.

I’ll write down the inadyn name. But I bet it will require building on my part, since the MBL uses an uncommon PowerPC CPU? Does it store the password for the dynDNS service in clear text or encrypted?

In fact, what would be the proper instructions to install the compiler? I am quite afraid of bricking the device by a wrong maneuver.

Is there a proper way to have it launched whenever the MBL is plugged in? See word of caution above: if the MBL fails to start due to an error in the startup script, then it’s bricked.

And would there be an application to automatically open relevant ports to the outside world when router may not be locally accessible? Ports 443, 80, 21 and 22 will be opened, and defaults passwords changed. I take note of the auto-ssh function. However I don’t have access to a permanently-connected Linux machine anywhere. And wouldn’t it render the connection from home to the MBL somewhat unreliable by adding yet another layer of complexity?

You don’t need to install the compiler or build it yourself. You can install the binary version with

sudo aptitude hold udevsudo aptitude install inadyn

 from an ssh terminal. The aptitude hold command is to ensure that a certain package is not updated, which would brick the MBL.

There are definitely options to start inadyn after boot automatically, but I never bothered doing that. I only reboot the MBL when there is an accidental power failure, after which I start the command myself. As far as I know, you can’t open ports in a router unless you have access to it. Establishing an outward connection first, such as reverse tunneling with an ssh session, and connecting to that one later, is the only option I know and I also actively use. This might shed some light on the technique: http://www.alexonlinux.com/reverse-ssh-tunnel-or-connecting-to-computer-behind-nat-router

Maybe someone else on this forum can help you with the remaining questions?

That’s interesting. Is there a list of packages that should NOT be updated to avoid bricking the MBL? Very short power outages do occur on a regular basis, as I hear the UPS’s relay clicking and lights briefly turn off.

Waiting for the other answers…

Based on this page, I would say udev is the only package that should not be upgraded: http://mybookworld.wikidot.com/mybook-live-update.

Seems legit. But when I started following their first line, I assume, to update signing keys

# aptitude install debian-keyring debian-archive-keyring

 I was greeted with a request to update a bunch of package. I am especially concerned about the big version jump in apt-utils, and the removal of aptitude.

Remove the following packages:
aptitude
libept0
tasksel
tasksel-data

Install the following packages:
libapt-inst1.5 [0.9.7.9+deb7u1 (stable)]

Upgrade the following packages:
apt-utils [0.7.20.2+lenny1 (now) -> 0.9.7.9+deb7u1 (stable)]

Score is 379

Accept this solution? [Y/n/q/?]

Yes, I’m quite afraid of bricking the MBL again. 

I didn’t mean to imply that you had to execute the command on the page I linked to. I merely linked to it as my source for the statement that the udev package shouldn’t be updated, and that it’s the only one as far as I know. This page: http://mybookworld.wikidot.com/mybook-live has the same information and a bit more. I wouldn’t recommend updating the whole MBL, but instead would just try to install the inadyn package only. It’s been a couple of years since I did that, so I can’t fully recall what I did, but I don’t seem to remember updating the whole system.

If you still use this MBL, would you care to verify if the password is stored in plaintext?

The password isn’t stored at all, if you just type it at the command line (though it can be stored in the bash history). It is stored in memory and visible when using tools like top. You need SSH access to the MBL for that though. If you use the configuration file, it is stored in plain text. Also then you need SSH access to the MBL in order to access this file.

However, depending on your DDNS provider, the DNS update request itself can be sent over the internet in plain text (see for example http://www.noip.com/integrate/request ), so anyone could intercept that request and extract the password. Your MBL is then the least of a problem, in my opinion.

Cheers

Interesting post. Leaving it in memory assumes no power outage occurs. However when it does occur, usually the modem resets to a new IP, precisely as the MBL would reboot and lose its ability to update its IP. I guess with a properly-passworded SSH, the plaintext password would only be sent out in clear when an IP change is detected? And thus remain only locally-vulnerable?

I first wanted to enable disk encryption as well, but considered the highly risky and added inconvenience not to be worth it. The DynDNS password is less important than the SSH one that would secure the video recordings.