Transport Sync – The hardware and the software

Since getting my Transport Sync and seeing reports that the drive when formatted by the unit may not be accessible by any other means. I thought I would investigate this further myself.

I took the external drive I was using and attached it to another Linux machine. As I expected when I did this I could see 3 partitions had been created on my external drive. The first was a 1GB (primary partition 1), followed by ~1.8G (logical partition 3 ) and the rest of the drive space (logical partition 4).

I’d heard that the drive my not be mountable outside of the unit/use. However, that’s not true. I could mount all the partitions and traverse the contents without an issue. However, the layout of the disk is not what you’d expect. See below, as your share name s in the web portal are linked to what looks to be a UUID type relationship.

# ls -la
total 48
drwxrwx---    7 embedded embedded      4096 Mar  9 21:36 .
drwxr-xr-x   18 embedded embedded      4096 Mar  9 20:20 ..
drwxrwx---    5 embedded embedded      4096 Mar  9 21:00 54f6e0afbe034963343d3082
drwxrwx---    2 embedded embedded      4096 Mar 12 21:53 54fd66fdbd1f46071996b985
drwxrwx---    6 embedded embedded      4096 Mar 12 12:07 54fd720c591f467c6196b991
drwxrwx---    8 embedded embedded      4096 Mar  9 21:27 54fd75569ac07c7e7896b97e
drwxrwx---    3 embedded embedded      4096 Mar  9 21:37 54fd77969ac07cf43196b97e
# pwd
/replicator/storagePools

Anyways, under these UUID named directories is the data that you would get under each of your shares etc.

I also pulled down a copy of the diag logs and reviewed those too, and noticed that rootfs for the Transport Sync is downloaded from connected data and is used to build the OS onto the external drive etc (including a network boot prior to that happening). Determined that Transport Sync when in a labmode or beta state would have ssh daemon enabled. Worked this out from the init.d scripts (nS50ssh) contained in the rootfs that was downloaded (rootfs-3.1.9.17914.tar).

Source: /etc/init.d/nS50ssh

start() {
    if /usr/bin/in-labmode || /usr/bin/is-beta || [ -e /replicator/configuration/ssh ] ; then
 	    echo -n "Starting sshd: "
	    /usr/sbin/sshd -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key
	    touch /var/lock/sshd
	    echo "OK"
    fi
}

I made some tweaks so that when I unmounted the drive and attached back onto my Transport Sync, it would boot and enable ssh. So I could dig a little more around, and can see the architecture information below of the system;

# cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 4 (v6l)
BogoMIPS        : 239.20
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb02
CPU revision    : 4

Hardware        : Connected Data CNS3411 Portal Board
Revision        : 0000
Serial          : 0000000000000000
# uname -a
Linux cd_haven 2.6.35.12-cavm1 #14 Tue Jun 24 14:51:41 PDT 2014 armv6l GNU/Linux

The program that seems to do all the heavy lifting is “replicator” and this is something connected data has developed, and has ties to Drobo as far as I can tell also.

I recently installed Windows 10 RC and installed the Transporter Desktop client on and was surprised to see that the Transporter Library shows up in Windows 10 RC as a drive letter, this was pretty cool I thought. So my D: drive on Windows 10 RC after installing the client is associated to the Transporter Library folder.