Home
Name Modified Size InfoDownloads / Week
components 2011-07-04
README 2011-07-12 6.8 kB
nas_server-0.1.1.tar.gz 2011-07-05 4.0 MB
nas_server-0.1.tar.gz 2011-07-04 4.0 MB
nas_client-0.1.tar.gz 2011-07-02 472.5 kB
Totals: 5 Items   8.4 MB 0
README for nas_server-0.1.1

This release combines the necessary component packages for a device to act as NAS (Networked Attached Storage) drive similar to the Linkstation series by Buffalo. The top level script simple calls ./configure etc in the correct order for the packages. The packages are:

libiniLoader: A c++ class to read .ini files. This started as an example to learn flex and bison from and may be replaced at some point, as it's not great.

libacppacket: A c++ class for an ACP packet, where ACP is the protocol used by Buffalo's NASNavigator software etc, to communicate with NAS drives.

acp_master: This daemon announces the device as a NAS drive to the network. It then listens for ACP packets from other devices and replies to them appropriately, allowing the device to show up as a NAS drive in NASNavigator and be visible to the Windows service (and equivalent Linux daemons) which wake up the device use WOL (Wake on LAN) commands. The conf file gives the location of the data partition and an optional second USB partition, which you might have to change. Details of these partitions are sent to NASNavigator. It also specifies the mtab file, but this shouldn't need changing if you are on Linux...

kas:	(Keep-Alive-Server) listens for incoming WOL packets. If none are received after an interval, the drive enters standby, otherwise the timer is reset. The kas daemon should not be started at boot, instead the inputmond daemon (more below) should start it if the device switch is set to Auto.

	kas uses a config file to learn about two scripts; the wake script and the sleep script. When a WOL packet is received, the timer is reset and the wake script is called. Currently this script does nothing. When enough time has passed without a WOL packet, the standby script is called.

	The default action of the standby script is to kill all processes; turn the fan off; unmount the data partition; turn swap off; load the kernel from /boot/uImage.buffalo into kexec (kexec-2.0.2 is required for ARM uImage support, otherwise you need to compile and specify a normal kernel); load an initrd disk image into kexec as well as some boot parameters; unmount the boot partition and finally, reboot (kexec) into the disk image. External drives aren't unmounted, they probably should be. The purpose of this is to run a low power standby distribution. A sample initrd is provided, which has telnet and (an older) copy of this software, which is set up differently (see below). This also allows the HDD to spin down as root is now in RAM. This standby script is quite specific, in the future it will be made more generic and perhaps something written to ask the user for some of the variables needed. NOTE that you will need to check that your partitions and their mount points are correct for this script. If you do not have a fan (i.e. not the same Linkstation I have) then you will need to remove the fan control line of the script.

	The sample initrd may also need customisation. By default, the provided initrd runs acp_master in standby mode (doesn't show up in NASNavigator, still visible to wake-up service). inputmond is also run, with different default actions. Kas is run at startup - if you're in the initrd, you're in standby mode and you might like to get out of it... The fan is set to go on every half-hour. Again, if you don't have a fan, you might like to change this. The various partitions are fsck'd. You will probably have to change what happens here, you might have different partition numbers for the boot, root and data partitions as well as different filesystems. Sometimes the filesystem needs to be set or fsck doesn't pick it up. This might be fixed in an update... The hard drive is the put into a standby state and the system left to wait for WOL packets. The kas server is again in charge of this. In this case, the wake and standby scripts are swapped round - standby does nothing and wake mounts the boot drive, finds a kernel file, specifies the partition to boot and kexecs to it. Once again, this will need some care if your system has different partitions etc. 'reboot' could have been called here, but I think this is slightly faster as it doesn't have to go through the uBoot code.

	The kas server's final trick is to only come out of standby if the MAC address telling it to wake up is not blocked. This is to prevent excessive spin down/up of the HDD by a [laptop] which only occasionally uses the drive but always wakes it up [and gets put into standby regularly itself!]. By letting kas know about the [laptop's] mac addresses (wireless and wired...), it will ignore wakeup requests from that device. However, it changes the behaviour of acp_master so that the sleeping NAS drive will show up in the NASNavigator of the blocked [laptop]. This means that when NASNavigator is launched, it will query acp_master for drive information as well as sending the normal discovery request. acp_master lets kas know that a blocked machine has asked for this information, which kas interprets as the blocked [laptop] user really wanting to use the NAS drive and so it runs the wake script. In short, if a blocked user wants to use the NAS drive, they only have to run NASNavigator.

inputmond: Monitors the function switch and the 'on/off/auto' switch. You can change the states to listen for as well as the actions in the config file. Currently, the states are taken by listening for an interrupt and then polling the switch. This seems a roundabout way of doing it, but listening for interrupts didn't catch all the events. This still doesn't, so if you move the 'on/off/auto' switch, it has to be done slowly. This might be down to (my) imperfect hardware or more likely, some kernel GPIO debouncing issue. If this gets identified in the future, I will patch the kernel and the inputmond daemon will be rewritten - but as it is I barely use the buttons and so this is not a priority. Of course, this may work better for you if you have a different model... The default actions for inputmond are to start/stop kas for the auto switch and to shut down when the switch is slid (slowly, via on!) to off. In standby mode, kas is always on, so inputmond reboots wherever the switch is moved to - if 'off' then uBoot will wait for the switch itself, otherwise it will continue to boot.


The kas daemon is the most fussy of the package, setting it up might take some work but from this README you should see what needs to be changed for your system. Once it is set up though, it works well. I've had this setup since ~August 2010 and have since been developing it to be more suitable for general use. It's still not release quality code, but perhaps one day it will be good enough to install to any custom Linux NAS drive :).
Source: README, updated 2011-07-12