Smartstor NS4600[]
The Smartstor 4600 is Promise's second generation 4-bay NAS appliance. It has a compact, reasonably attractive enclosure, a low noise level, and provides a decent set of features for a reasonable price. And as you'd expect from most NAS devices around today, it runs embedded Linux.
Unlike higher-end devices from QNAP or Netgear, Promise do not provide direct access to the Linux environment, so we have to do some hacking to get that access, but once we have it, there's plenty of interesting things to do.
The Hardware[]
lspci Output[]
00:00.0 Host bridge: Intel Corporation EP80579 Memory Controller Hub (rev 01) 00:00.1 Class ff00: Intel Corporation EP80579 DRAM Error Reporting Registers (rev 01) 00:01.0 System peripheral: Intel Corporation EP80579 EDMA Controller (rev 01) 00:02.0 PCI bridge: Intel Corporation EP80579 PCI Express Port PEA0 (rev 01) 00:03.0 PCI bridge: Intel Corporation EP80579 PCI Express Port PEA1 (rev 01) 00:04.0 PCI bridge: Intel Corporation EP80579 PCI-PCI Bridge (transparent mode) (rev 01) 00:0a.0 Class ff00: Intel Corporation Device 5038 (rev 01) 00:1d.0 USB Controller: Intel Corporation EP80579 USB 1.1 Controller (rev 01) 00:1d.7 USB Controller: Intel Corporation EP80579 USB 2.0 Controller (rev 01) 00:1f.0 ISA bridge: Intel Corporation EP80579 LPC Bus (rev 01) 00:1f.2 RAID bus controller: Intel Corporation EP80579 S-ATA Reserved (rev 01) 00:1f.3 SMBus: Intel Corporation EP80579 SMBus Controller (rev 01) 00:1f.4 Performance counters: Intel Corporation Device 5036 (rev 01) 02:00.0 RAID bus controller: Promise Technology, Inc. PDC42819 [FastTrak TX2650/TX4650] 03:00.0 Ethernet controller: Intel Corporation EP80579 Integrated Processor Gigabit Ethernet MAC (rev 01) 03:01.0 Ethernet controller: Intel Corporation EP80579 Integrated Processor Gigabit Ethernet MAC (rev 01) 03:03.0 Class ff00: Intel Corporation EP80579 Global Control Unit (GCU) (rev 01) 03:07.0 Communication synchronizer: Intel Corporation EP80579 IEEE 1588 Hardware Assist (rev 01) 03:08.0 Bridge: Intel Corporation EP80579 Local Expansion Bus (rev 01) 03:09.0 Co-processor: Intel Corporation EP80579 Integrated Processor ASU (rev 01) 03:0a.0 System peripheral: Intel Corporation EP80579 Reserved (rev 01) 03:0c.0 Performance counters: Intel Corporation EP80579 Reserved (rev 01)
CPU: Intel EP80579[]
The heart of the NS4600 is an Intel EP80579 ("Tolapai") SoC. That means it runs the same x86 code that most PCs do. In fact, the CPU core of the SoC is a 600MHz Pentium M, which was a respectable Laptop CPU circa 2005. The SoC also provides all the essential I/O devices with the exception of the RAID controller, which is unsurprisingly a Promise part.
/proc/cpuinfo[]
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 21 model name : Genuine Intel(R) processor 600MHz stepping : 0 cpu MHz : 598.523 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx constant_tsc bogomips : 1198.24 clflush size : 64
RAID Controller: Promise PDC42819[]
The Promise PDC42819 is the raid controller chip used on Promise's FastTrak TX2650/TX4650 cards, and is connected to the EP80579 over a PCI-Express link. The extent to which this is a hardware accelerated RAID controller is unclear - most Linux related docs say no, but I observe that the CPU isn't doing any work during an array rebuild, so something else must be doing it!
Other hardware of note[]
You'll notice from the lspci output that the NS4600 has two ethernet devices, and if you run ifconfig, you'll see both of them - but there's only one physical port on the back. Some of the early promo material said it would have two ports, but I guess they cut the second one in the end.
There's also an Intel SATA controller - this is the one that drives the E-SATA port.
The Software[]
Unsurprisingly for an embedded device, the NS4600 doesn't run a standard Linux distribution. For the purposes of this discussion, I am assuming the SR1 firmware upgrade.
The Kernel[]
Linux smartstor 2.6.20.21-4600 #32 PREEMPT Mon Aug 31 17:15:48 CST 2009 i686 unknown
We see that it's running a surprisingly old kernel - probably because this is the one Intel used in their original SDK - I'd imagine recent ones work just fine, although even x86 embedded devices can have odd one-off requirements.
Kernel Modules[]
Only a handful of modules are provided, with everything else compiled in. There are three notable drivers - two are Intel provided and drive the GCU and Ethernet devices. These drivers are open-source but not integrated into upstream. You can find them on the EP80579 pages. The third driver is t3sas, Promise's partially open-source driver for the RAID controller. It is version 1.1.0.36 while the latest publicly available source is for 1.1.012. Linux has support for the hardware but only when using it as an AHCI controller - meaning you give up the RAID capabilities (and the ability to use SAS drives). The lack of source for t3sas would be the main obstacle to compiling a newer kernel.
Userspace[]
The userspace is pretty typical for an embedded system - relying heavily on BusyBox. Perhaps notably, it uses glibc 2.3.6 and appears to have been compiled with gcc 4.1.2.
Hacking the NS4600[]
Caveat[]
The NS4600 is not designed for direct Linux access, so if you attempt to do it anyway and you're not careful, you may render your device unusable, and won't receive a very sympathetic ear from Promise if you ask for help. While the NS4600 is robust against most of the usual ways you could hose the system, it is still absolutely possible to do so; Do not follow these instructions or install any of these plugins if you don't fully understand the risks involved.
Getting In[]
While the NS4600 is very similar to the previous generation NS4300N and NS2300N, it's sufficiently different that none of the old turn-key hacks work anymore. Fortunately, I found this guide explaining how one of the old manual methods can still be used. The process described is rather tedious, and hardly what you'd want to do on a regular basis. What we really want is a mechanism that automatically enables access.
Plugin based hacks[]
As a device where direct Linux access is disallowed, the NS4600 runs almost all processes as root; this is a common habit in such devices. Importantly for us, it means that if we can create or modify a plugin, we can make that plugin do all the work needed to get us Linux access. This trick was implemented for the NS4300 - most comprehensively in the SSH plugin. The NS4600 plugin format is different but only in a couple of specific ways.
The NS4600 Plugin Format[]
The plugin directory[]
At the heart of a plugin is the actual plugin directory that contains the binaries, configuration files, and any other required bits for the plugin. The contents of the directory can be organised however you wish, but typically you would follow unix conventions and have:
binorsbin: Binariesetc: Configuration fileslib: Required shared librariesshare: Data files
plugin.conf[]
Inside the plugin directory, you must add a file called plugin.conf so that the system can recognize your plugin as a plugin.
Here is the ushare plugin.conf as an example:
APPNAME=USHARE APPSTRING=uShare VERSION=01.01.0000.01 AUTOSTART=YES SWAPMEM=YES APPBINDIR=bin EXTLIBDIR=lib MAINPROCESS=ushare CONTROLSCRIPT=ushare_control
- APPNAME: The name of the plugin directory.
- APPSTRING: The name shown in the NS4600's web interface
- VERSION: The plugin version
- AUTOSTART: Whether to automatically start the plugin when the system starts
- SWAPMEM: Whether the plugin requires the NS4600 to turn on swap (almost always say YES)
- APPBINDIR: Directory under the plugin directory that contains the CONTROLSCRIPT
- EXTLIBDIR: Directory under the plugin directory that contains needed shared libraries. Leave this line out if it's not needed
- MAINPROCESS: Name of the service process for the plugin. Leave this line out if it's not needed
- CONTROLSCRIPT:
initstyle script that starts and stops the plugin
The CONTROLSCRIPT[]
The control script is much like the typical scripts you find in /etc/init.d on a normal Linux system. It gets called with 'start' or 'stop' to start or stop the plugin. The environment variable APP_PATH is set to tell the script where the plugin lives.
Here is the ushare control script as an example:
#!/usr/bin/perl
$app_path = $ENV{'APP_PATH'};
print "APP_PATH = $app_path\n";
$action = $ARGV[0];
if ( $action eq "start") {
print "Starting ushare...\n";
system("sudo $app_path/bin/ushare -f $app_path/etc/ushare.conf -D");
}
elsif ($action eq "stop") {
print "Shutting down ushare...\n";
system("sudo /usr/bin/killall ushare");
}
The rev file[]
Another important file is the rev file. It is part of the packaged plugin but not the installed plugin, and lives in the top level directory that you build your plugin from (see below). It tells the plugin installer about the plugin.
Here is the ushare rev file as an example:
PKGNAME=ushare PKGVERSION=01.01.0000.01 FWVERSION=02.01.0000.10
- PKGNAME: The name of the directory containing the plugin directory (will make sense shortly)
- PKGVERSION: The version of the plugin
- FWVERSION: The minimum firmware version that the plugin is compatible with (02.01.0000.10 is the SR1 firmware)
Additionally, one other option is available:
- FIXSCRIPT: Name of a script to run at install time. I have no examples of this but think of it like the post-installation script used by DEBs or RPMs.
Building the plugin tarball[]
Once you've got your plugin directory and rev file, you need to put them together in a gzipped tarball. Here is the contents of the ushare tarball:
-rw-r--r-- philipl/users 64 2010-02-15 10:59 rev drwxr-xr-x philipl/users 0 2010-02-15 10:59 ushare/ drwxr-xr-x philipl/users 0 2010-02-15 11:03 ushare/USHARE/ drwxr-xr-x philipl/users 0 2010-02-15 11:03 ushare/USHARE/etc/ -rw-r--r-- philipl/users 1314 2010-02-15 11:03 ushare/USHARE/etc/ushare.conf drwxr-xr-x philipl/users 0 2010-02-15 11:02 ushare/USHARE/bin/ -rwxr-xr-x philipl/users 82770 2010-02-15 10:58 ushare/USHARE/bin/ushare -rwxr-xr-x philipl/users 362 2010-02-15 11:02 ushare/USHARE/bin/ushare_control -rwxr-xr-x philipl/users 156 2010-02-15 11:01 ushare/USHARE/plugin.conf drwxr-xr-x philipl/users 0 2010-02-15 11:01 ushare/USHARE/lib/ lrwxrwxrwx philipl/users 0 2010-02-15 11:01 ushare/USHARE/lib/libupnp.so.3 -> libupnp.so.3.0.5 -rwxr-xr-x philipl/users 44511 2010-02-15 10:55 ushare/USHARE/lib/libixml.so.2.0.4 -rwxr-xr-x philipl/users 122790 2010-02-15 10:55 ushare/USHARE/lib/libupnp.so.3.0.5 lrwxrwxrwx philipl/users 0 2010-02-15 11:01 ushare/USHARE/lib/libixml.so.2 -> libixml.so.2.0.4 -rwxr-xr-x philipl/users 21272 2010-02-15 10:55 ushare/USHARE/lib/libthreadutil.so.2.2.3 lrwxrwxrwx philipl/users 0 2010-02-15 11:01 ushare/USHARE/lib/libthreadutil.so.2 -> libthreadutil.so.2.2.3
Notice how the plugin directory USHARE is inside another directory named ushare to match the PKGNAME directive in the rev file.
Obfuscating the tarball[]
For reasons known only to Promise, plugin tarballs have to obfuscated - and the obfuscation mechanism changed for the NS4600 (every step until now is the same for the older NS4300n and NS2300n).
Adding the header[]
The first step is to prepend 92K of zeros to the tarball. (For the older devices, it's 97K). You can do that with the following commands:
dd if=/dev/zero of=./plugin bs=1K count=92 cat tarball.tgz >> plugin
Encrypting the plugin[]
A completely new step for the NS4600 is to 'encrypt' the plugin. It's not very effective encryption as the encryption is symmetric and the decryption tool is on the device. What they have done is use a modified build of the bcrypt tool. They have modified it to use a fixed encryption key ("30570000") and to change the default extension used by encrypted files - otherwise it appears to be the same. I imagine it would be pretty trival to extract the actual key from their binary, but that's not even necessary as the /sbin/bcrypt on the device can encrypt as well as decrypt - and as it's a simple x86 binary, you can probably copy it to your build machine to run it. Due to the unspecified licensing on the binary (original source is BSD licenced), I will not distribute it here; you can just copy it off the device once you've got the telnet plugin installed.
It's simple to use:
bcrypt plugin
to yield a plugin.pef file. Rename this to plugin.ppg and you're ready to go! Just upload it through the plugin installer.
Building and Testing plugins[]
Building binaries[]
As mentioned earlier, the NS4600 is an x86 machine and uses glibc 2.3.6. That's a bit old so your modern desktop is unlikely to produce compatible binaries. I ended up using a Slackware 11.0 Virtual Machine as the glibc matches, but I'm sure you can use OpenEmbedded with great success.
Testing plugins[]
You can test plugins without packaging them by simply copying the plugin directory into /APP on the device. It will appear in the web UI and you can start or stop it.
IPKG/Optware[]
A recent addition of the syno-i686 optware feed allows one to install and run many precompiled binaries. With a little effort it's possible to get many useful utilities, like tranmission and dropbear ssh working. One can manually install wget and the ipkg pakage manager by simply renaming and ungziping the .ipk file, and creating a proper directory tree. it takes a bit of hacking around is very useful.
Available Plugins[]
Telnet[]
Telnet is always available on the NS4600, but you cannot log in as any user which you know the password of. This plugin allows the admin account to log in, and also gives it sudo rights, so that you can do any task that requires root - including changing the root password to allow direct telnet log in as root. Note that the root password is reset on every power-cycle, so you must use admin to reset the password each time.
You can telnet to your NS4600 on port 2380. Note that a given user cannot connect be over connected over multiple simultaneous connections.
You can download the Telnet Plugin here.
LLink[]
LLink is a simple, but effective, media file server for Popcorn Hour/Networked Media Tank devices. While these devices can access media files over NFS or CIFS, those protocols have maximum streaming bitrate limits that are lower than for http based transfers. As such, an http based server like LLink is a perfect service to run on the NAS.
This plugin comes configured to export the NS4600's standard VIDEO share. If you want to change the export list or the skin, you can edit the config file found at /APP/LLINK/etc/llink.conf. Changes will be remembered until you install or upgrade the plugin.
You can download the LLink Plugin here.
[]
uShare is a very simple UPNP server from the GeeXboX project. While the NS4600 ships with a much more feature-full DLNA-compliant server, it has the big disadvantage of needing to do a very heavyweight scanning process to find your media files - and the scan has to be redone when you add or remove files. uShare has the virtue of doing the scan at startup in a very short amount of time (you will need to restart the plugin to pick up file changes)
This plugin comes configured to export the NS4600's standard VIDEO share. If you want to change the export list, you can edit the config file found at /APP/USHARE/etc/ushare.conf. Changes will be remembered until you install or upgrade the plugin.
You can download the uShare Plugin here.