[Announce] NAS-CC: Alternate firmware for NAS200 without any services!

Discussion in 'Cisco/Linksys Network Storage Devices' started by alejandro_liu, Sep 11, 2008.

  1. alejandro_liu

    alejandro_liu Addicted to LI Member

    Announcing release of my NAS200 firmware mods

    Please read the entire posting before you begin!

    Hi, I am pleased to announce a new alternative firmware for the NAS200. Unlike other NAS200 firmware, my firmware actually has the least amount of functionality available from any competing NAS200 firmwares.

    It does however allow you to boot other firmwares from a storage device (SATA or USB).

    It can be found here:

    SourceForge project page

    Downlaod page: SourceForge

    As usual, use at your own risk! I will not be responsible if your data or configuration disappears, if you brick your box or if you let the Magic Blue Smoke escape. I recommend making a backup or everything (data, configuration, firmware) before you start.


    1. Create and populate a boot share
    2. Flash your device with the nascc-boot.bin firmware file
    3. Reboot

    To create a boot share you must create a share in the root of any of the SATA volumes named either "boot" or "etc". This will work even if your NAS200 is configured as independant drives, JBOD, RAID1 and RAID0. Alternately, you can simply create a "boot" or "etc" directory on a USB drive, or just use the root directory of the USB drive.

    In this boot share/directory, you must copy a firmware file. Usually is a file of 8MB size that has a .bin extension.

    You must now create a file called: fwboot42.sh with a line:


    Replace NAME_OF_FW_.bin with the actual name of the firmware file.

    To flash yor device, you must download the tar-ball containing the firmware and use the nascc-boot-XXX.bin file.

    To do this, simply download it through the Firmware Upgrade webpage of the NAS200 web GUI. You will get a popup saying that your NAS200 will reboot in 30 seconds, and the NAS200 will beep and all lights will go on when it reboots. Click OK on the notification.

    At this point you have a NAS200 with a very basic firmware, however this firmware is able to boot a more full-featured firmware either from a USB drive or from your SATA disc.

    Make sure you read the included README file for all the options available with the boot firmware.

    If you have a serial port connected, you can see what's going on.

  2. ribe

    ribe Guest


    Thanks for NAS-CC, this is exactly what I was after!

    A couple of bugs to report:

    First, I'm using ext3 and if any of the inserted drives were not cleanly unmounted, then the firmware fails to finish booting - it just hangs. To work around this, I'm removing all drives, booting it into failsafe mode, then hotplugging the drives to fsck them. For anyone who ends up needing to do this, echo '- - -' > /sys/class/scsi_host/hostX/scan to rescan for SATA drives and note that the partition labels will probably end up different.

    Second, I'm having trouble getting a chroot script to work. It seems to run the script and pivot_root, but fails to exec (my) init. /rc (pid 1) is stuck on pipe_wait (from /proc/1/wchan), there are a ton of zombie mount processes and a zombie /rc (pid > 1). Looking at /rc, I think it has successfully run tryboot, but has not done anything after that point.

    It has not unmounted /sys (though incidentally that should be /mnt/sys as this is after the pivot) and its fds (from /proc/1/fd) are connected to /mnt/dev/console, not /dev/console as I would expect.

    I've not had to open up and connect a serial cable yet, so that's all the information I have - I had my chroot script run a telnetd so that I could get in.

    Any ideas?
  3. dsc68

    dsc68 Addicted to LI Member

    I don't know if Alex is supporting NAS-CC anymore. There hasn't been any activity in the project for a few months and the current source no longer builds due to out of date dependencies.
  4. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    I would encourage Alex to continue the work on NAS-CC. Just this week I finally had a chance to look at the source code and I was impressed by how it was organized. I haven't had a chance to try it, although I'm very interested because I'm starting to get really worried about the wear and tear on my flash (I've been using the serial port and the Redboot command prompt to load my firmware straight to RAM by TFTP).

    I noticed NAS-CC is based on Buildroot, and so is OpenWRT. Both the Linux kernel and OpenWRT (and presumably Buildroot) now support the RDC chip (kinda -- the gpio and platform modules are still very hardware-specific and are probably unusable for the NAS200). However, correct me if I'm wrong but it looks like NAS-CC uses an older snapshot of Buildroot that doesn't have RDC support in it yet.

    I've been looking at OpenWRT and OpenEmbedded as candidates for possible projects to add NAS200 support to. The reason is that NASi200 is progressing way slower than I would like and it makes sense to use a stable system that has lots of users and that makes it easy to add new software that we haven't even thought of. The main disadvantage is that we would lose all the Linksys functionality (at least initially until we reverse-engineer some of the closed source stuff) so this would make it less interesting for users with little Linux experience.

    I was glad to see that Alex has already reverse-engineered some closed-source Linksys stuff, like the 'bind' image builder and the Set_Led tool. Actually, I just used some code from that tool (nasctl.c) to hack the Jac2 kernel a little so that the NAS200 now powers down and resets as expected. Tune in to this forum for more news about that, soon!

  5. dsc68

    dsc68 Addicted to LI Member

    Yes, NAS-CC uses an old version of Buildroot. It is currently broken because one of the library modules included is an old version that is no longer available.

    I'm currently working with Buildroot to build a custom NAS200 firmware at the moment. Stay tuned for more soon as well.
  6. alejandro_liu

    alejandro_liu Addicted to LI Member


    I haven't have time to do much on my NAS-CC software. I recently moved to a new house and I still don't have Internet at home. I still have a lot of things on my todo list for NAS-CC.

    I will take a look at the bugs reported by ribe. However, currently I am very limited with my hacking time.

    Similarly, thanking for reporting the build problems, do you care to report which were the out-of-date dependancies? I typically don't test these fully as I usually donload them to my disc and use my offline copy.

    If you tell me which old library module is no longer available I should be able to put it up for download.

    Some comments, I was using the most recent buildroot at the time. In theory I tried to keep the changes to buildroot as limited (or as unintrusive) as possible, so switching to a newer buildroot shoud work (without much hacking). However, this is not always trivial.

    My plan was to take a frozen version of buildroot, use it for a few months and then upgrade to a newer version. (buildroot gets updated nearly daily).

    Like Jac did, I also took a look at OpenWRT (but not OpenEmbed). The thing I did not like about OpenWRT is that it pulls in quite a lot of hardware dependant stuff which was very complex for me to understand and I was not going to be able to use. So I chose buildroot instead (which starts of more generic) and added the NAS200 dependant bit.

    Adding new software to buildroot is not too complicated.
  7. dush

    dush Addicted to LI Member

    Is there any activity at all in this project? If so, could you provide the latest tree you got? I'd like to make some changes and upgrade it to more recent versions but it could be useless if you already got a new tree :)
  8. dush

    dush Addicted to LI Member

    Or do you have anything new already dsc68?
  9. dsc68

    dsc68 Addicted to LI Member

    buildroot is preparing a new stable version at the moment. When their stable version comes out I'll look at building a NAS200 version.
  10. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    How about some instructions on building NAS-CC using an SVN snapshot of buildroot?

    Alex, there are no instructions anywhere on how to build it. Or am I missing something?

  11. dsc68

    dsc68 Addicted to LI Member

    From what I have been able to determine, the sequence to build the firmware is:

    1. Unpack the nascc tarball
    2. Copy the buildroot tarball to the nascc directory
    3. Edit the line in the Makefile which specifies what release of buildroot you are going to use
    4. Clone one of the packaged profiles to your new <profile> with ./mk clone std <profile>
    5. Unpack the build directory with ./mk unpack <profile>
    6. Modify the profile config with ./mk <profile> menuconfig
    ./mk <profile> busybox-menuconfig
    ./mk <profile> uclibc-menuconfig
    ./mk <profile> linux26-menuconfig
    7. Build the firmware with ./mk <profile>
    8. Package the firmware with ./mk <profile> firmware

    However, I haven't been able to get a successful build. The included buildroot is out of date and one of the included packages is no longer available (I can't remember which off the top of my head). Using a more recent buildroot runs into problems with the various patch files not working - though as far as I can determine most of them are no longer required particularly with the RDC support now included in the kernel. buildroot is also has been a bit unstable recently as they are working towards a stable release.

    I've also had problems with Alex's binaries not work as intended. The boot firmware doesn't seem to run all of the initialisation scripts of the replacement environment properly.
  12. alejandro_liu

    alejandro_liu Addicted to LI Member

    dsc68 got it allmost right.

    First you must unpack the nascc tarball and place the buildroot tarball in there.

    There are three profiles, boot, bare and std. Only boot is meant to be flashed into the NAS flash. To get a new boot firmware the steps are:

    1. ./mk unpack boot
    2. ./mk boot
    3. ./mk firmware boot

    The other profiles tend to be too large to fit in the flash. To create your own profile (that will be chainloaded by the boot profile)

    1. ./mk clone std <profile>
    2. ./mk unpack <profile>
    3. ./mk <profile>

    This will create a kernel and a root file system in binaries/<profile>, these need to be put in a boot partition.

    Unfortunately I am still without Internet so I can't check which package is out of date still.

    Once I do, I will either post the missing dependancy or a new patch.

    On the boot firmware not running all of the initialisation scripts, that could be, as I did not test the chroot stuff fully.
  13. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member


    Thanks guys!

  14. dsc68

    dsc68 Addicted to LI Member

    I've traced the problem with the init scripts to sysinit failing because it tries to fsck the mounted root volume. Adding -r to the fsckoptions fixes the problem.
  15. alejandro_liu

    alejandro_liu Addicted to LI Member

    Hi dsc68,

    What does -r do? According to the man page it says:


    This option does nothing at all; it is provided only for backwards compatibility.
  16. dsc68

    dsc68 Addicted to LI Member

    Sorry, my wrong - I meant -R

    -R When checking all file systems with the -A flag, skip the root file system (in case it's already mounted read-write).

    rc.sysinit fails without the option because the root partition is already mounted r/w

    Alternatively it could be that the root partition is mounted as r/w at this stage when it should be r/o
  17. alejandro_liu

    alejandro_liu Addicted to LI Member


    Finally got my Internet so I posted a new version of my firmware 0.1.3rc1. Contains bug fixes to all the bugs listed in this thread. i.e. chroot script bug, the -R flag for fsckoptions, the ONE URL that was out of date was corrected, etc.

    So this one is buildable. It still uses an old buildroot snapshot. I am waiting for Jac to finish his gentoo work before I move to the current buildroot release.

    Finally, I compiled an AoE server. However, this feature has not been tested.

    You can download this from: sourceforge.net
  18. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Thanks for your work Alex, but I don't think I'll have time for Gentoo or OpenWRT for at least the next 3 weekends... :frown:

    The latest update is that I can't get OpenWRT (which is based on buildroot) to work because it refuses to recognize the SATA controller; the Gentoo kernel does recognize the SATA controller and hard disks but has a problem with the network adapters. I have a funny feeling that the fact that the Linksys firmware sets the network adapter to promiscuous mode to work around whatever the problem is.

  19. dsc68

    dsc68 Addicted to LI Member

    Thanks Alex,

    I suspect the -R flag issue is actually a work around for a different problem. The root partition should really be mounted as R/O up until after the the fsck section of the rc.sysinit script, after which it should be remount as R/W. As it is now, the root partition will never be fsck'ed.

    Another issue I have encountered is that if you use a hard coded IP address instead of DHCP, there is no where to set a default gateway. rc.d/network just needs a route command included after the ifcfg.
  20. jackito

    jackito LI Guru Member

    Hi Alex,

    Im curious, which AoE server did you compile? vblade? which version?
    I was working on this the last three days and a I managed to compile and run successfully "vblade-16". But that is the last version that works for me.
    I started with 19 (last one) that didn´t work an from that point I started to downgrade until I get 16 up and running.

    I transfer a few files but the performance is really poor that´s why I´m planning to try other implementations (mostly kernel modules instead of userspace apps) in the quest of better performance.
    It seems to me that iSCSI is a lot lot faster.
    Anyway if anybody is interested in benchmarking vblade, let me know and I will upload the binaries.

    Keep improving! :thumbup:


    PS: I couldn´t format an AoE device from my Windows Vista workstation with NTFS. It keeps failing but I didn´t have problems with FAT32. Weird don´t you think? With iSCSI I didn´t have any problems.
  21. jackito

    jackito LI Guru Member

    I also noted that Jac but I couldn´t understand why.
    I disable the promiscuous mode on the network adapter but everything is still OK.
    I though that by doing that maybe the NIC or the system was going to have a little better performance. Silly me.... :frown:
    I couldn´t think of a way yet to get 2 or 3 more MB/s from this little friend.
    iSCSI didn´t do the trick and AoE was a lot more dissapointing.
    Anyway I will keep searching, reading and thinking, at least is a good exercise. :tongue:
  22. alejandro_liu

    alejandro_liu Addicted to LI Member


    As usual, documentation is always lacking...

    1. 1. The default root install would configure the root partition to mount read-only, however this can be changed in the boot script file. Actually, root is designed to ALWAYS run read-only. You only need to mount your /etc and /var read-write and mount exported filesystems under /data (again rw)
    2. If you want to configure to use static IP address you need to create a file /etc/config.d/network and in there place the following:
      You can specified more than one name server if you surrond them with quotes and separate with spaces.

      For example:

    The AoE server that I compiled was qaoed v0.81 from http://pi.nxs.se/~wowie/. I picked that one because it is multithreaded and can be configured from a file.

    The kernel that I compile does not set the interface to PROMISC. On the other hand I did not have that much time to work on the NAS200... This post was just a collection of a bunch of stuff that I did for the 4 months that it took my Internet to get connected (don't ask!)

    One SAN protocol that sounds interesting would probably be NBD. I found that qemu comes with a qemu-nbd server. While this will not make things faster, it is supposed to support COW images (Copy-on-write).
  23. jackito

    jackito LI Guru Member

    Hi Alex, did you test/benchmark qaoed?

    I compile it for jac2b and also vblade (I´m working on a kernel module AoE target know which seems to be a little more harder to compile but maybe a little bit faster when running). Anyway a test both of them with very laaaaame results. No more than 1050KByte/s (aprox 1 MB/s) for writings and even worst for reading, a little bit more than half the speed of writing, around 750KB/s.
    I´m using a regular file for export with both of them and also with iSCSI. And in my experience iSCSI is more than 4-5 times faster than AoE in opposition to the theory. :confused:
  24. alejandro_liu

    alejandro_liu Addicted to LI Member

    Yup, nothing better than practical testing to prove/disprove theory.

    I think the conclusion can be made. NAS200 is just slooow...
  25. jackito

    jackito LI Guru Member

    Finally I´m getting convince of that frustration after frustration.... :frown:
  26. alejandro_liu

    alejandro_liu Addicted to LI Member


    I uploaded a new NASCC firmware version. As always, it can be found here:


    This version goes back to basics. Essentially means that NASCC is 1st stage boot firmware. Most of the functionality is meant to be provided by the 2nd stage environment.

    This version is more compatible with the vendor supplied firmwares in the sens that now you can put your boot scripts in the DISK_1 or PUBLIC_DISK shares of your NAS200. (It can be either on the root or on a /boot or /etc folders).

    I am currently using this version to boot into CentOS.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice