Lm-sensors in net-snmp

Readout of integrated motherboard sensors was already a topic here, for VIA Epia boards and for WD Mybook World Edition as well. Such data is good to have visualized, so plotting it using MRTG was discussed too. This tool and its fundamental, net-snmp was designed to visualize network traffic data, so for sensor readings, an external script had to be constructed, which was quite inconvenient.

There is however a better way, briefly mentioned by lm-sensors.org, for which net-snmp has to be installed from source (download here, install instructions here) and has to be configured with the following options:

~$: cd net-snmp

~$: ./configure --with-mib-modules="ucd-snmp/lmsensorsMib" --with-ldflags="-lsensors" 

~$: make

~$: sudo make install

If installation was successful, lm-sensor readouts can be accessed via snmp, the same way as if they were polled by the command-line sensors tool:

~#: sensors

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +33.0 °C  (high = +78.0 °C, crit = +100.0 °C) 

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +32.0 °C  (high = +78.0 °C, crit = +100.0 °C) 

~#: snmpwalk -v 2c -c public localhost Sensors

LM-SENSORS-MIB::lmTempSensorsIndex.1 = INTEGER: 1
LM-SENSORS-MIB::lmTempSensorsIndex.2 = INTEGER: 2
LM-SENSORS-MIB::lmTempSensorsDevice.1 = STRING: Core 0
LM-SENSORS-MIB::lmTempSensorsDevice.2 = STRING: Core 1
LM-SENSORS-MIB::lmTempSensorsValue.1 = Gauge32: 33000
LM-SENSORS-MIB::lmTempSensorsValue.2 = Gauge32: 32000

Sadly, only CPU core temperatures can be read out for ICH8/ICH9 chipsets at the moment, still it is now way easier to integrate lm-sensor readings to net-snmp based logging and plotting tools such as MRTG.

WD MyBook Hacks - MRTG

This post is about using the versatile MRTG tool visualize usage data and health status of the storage device.

Prerequisites

• Web server to see the plots over http. For this the built-in mini_httpd will do, but lighthttpd is good as well if installed already. I however advice to use the first if there is no other reason for using the second one so that the configuration of the server does not have to be altered.
• Ipkg packages: cron, net-snmp and mrtg (also installs libgd and perl). The first is for periodic execution of the data acquisition, while net-snmp will collect the data which will be visualized by mrtg. Luckily again, these packages work out of the box, no compilation is required. For the usage of ipkg see my post on the basic setup.
• For cron and net-snmp to start on device startup, copy the contents of /opt/etc/init.d to /etc/init.d.

Setup MRTG

This can be done by using the built-in tool cfgmaker, for which the usage reference can be found here. The basic setup includes measuring the throughput of the ethernet interface:

#~: cfgmaker --global 'WorkDir: /proto/SxM_webui/mrtg' --global 'Options[_]: bits,growright' --output /opt/etc/mrtg.cfg public@localhost 

which sets up WorkDir where the graphic output and html files will be stored to be in the working directory of the html server. The config file will be stored at /opt/etc/mrtg.cfg.

I realized however that usage of the cfgmaker tool is not displayed in case of an input error or issuing --help. It seems that the /opt/lib/mrtg2/Pod/Usage.pm file shipped with the package is broken and has to be replaced with the one found here.

This basic config can be tested by issuing:

#~: mrtg /opt/etc/mrtg.cfg

at least twice and checking the result in the browser at http://IP_of_storage/mrtg/localhost_2.html (localhost_1 would be the loopback interface which is not plotted). The data can be collected automatically by adding the following line to /opt/etc/crontab:

*/5 * * * * root /opt/bin/mrtg /opt/etc/mrtg.cfg

and restarting the cron daemon:

#~: /etc/init.d/S10cron

This tells cron to run mrtg every 5 minutes. According to the mrtg manual it is not recommended to make it more frequent, and this value is usually good choice anyway.

Eventually, graphs will be filled with data like this:

This is good, but we can go even further: CPU load, memory and hard disk usage and temperature data can be plotted as well. The first three data values can be collected by net-snmp, while for the last one we need to modify the script that I have posted already:

#!/bin/sh

Y1=`cat /sys/module/thermAndFan/parameters/current_temp `

C1='display(0);config("tilde","off");3865/(ln('
C2=')+9.1411)-273.16'

/usr/sbin/smartctl -a -d ata /dev/sda | awk '/Temperature/ {print $10}'
/opt/bin/calc $C1$Y1$C2 | awk 'NR==3 {print $1}'
echo 0
echo Temperature Data on Storage
exit 0

The output of this script will consist of four lines that are needed by mrtg:

1.  "Input bytes" data: Here it will be the temperature of the hard disk;
2. "Output bytes" data: Here it will be the temperature of the system thermometer;
3. Uptime: we don't need this so set it to zero.
4. Text output: the name of the plots.

 I saved this script to /opt/etc/mrtg/tempscript1.sh which we will need in the revised mrtg.cfg:

# Created by
# /opt/bin/cfgmaker --global "WorkDir: /proto/SxM_webui/mrtg" --global "Options[_]: bits,growright" --output /opt/etc/mrtg.cfg public@localhost

EnableIPv6: no
WorkDir: /proto/SxM_webui/mrtg
Options[_]: bits,growright

LoadMIBs: /opt/share/snmp/mibs/HOST-RESOURCES-MIB.txt

kilo[_]: 1024
XSize[_]: 600
RouterUpTime[_]: hrSystemUptime.0:public@localhost

### Interface 2 >> Descr: 'eth0' | Name: 'eth0' | Ip: '192.168.1.1' | Eth: '' ###

Target[localhost_2]: 2:public@localhost:
SetEnv[localhost_2]: MRTG_INT_IP="192.168.1.1" MRTG_INT_DESCR="eth0"
MaxBytes[localhost_2]: 12500000
Options[localhost_2]: nobanner,noborder,growright,transparent
Title[localhost_2]: Traffic Analysis for eth0
 
### CPU

Target[localhost.cpu]: hrProcessorLoad.768&hrProcessorLoad.768:public@localhost
Title[localhost.cpu]: CPU Load
PageTop[localhost.cpu]:Active CPU load 

MaxBytes[localhost.cpu]: 100

Unscaled[localhost.cpu]: ymwd
Options[localhost.cpu]: growright,gauge,nopercent,noo,transparent,nolegend,nobanner,noborder
YLegend[localhost.cpu]: %
ShortLegend[localhost.cpu]: %
LegendI[localhost.cpu]: Processor Load

### Temperature

Target[localhost.temp]: `/opt/etc/mrtg/tempscript1.sh`
Title[localhost.temp]: Temperature Reading
PageTop[localhost.temp]: Temperature reading 

MaxBytes[localhost.temp]: 75

Unscaled[localhost.temp]: ymwd
Options[localhost.temp]: growright,gauge,nopercent,transparent,nolegend,nobanner,noborder
YLegend[localhost.temp]: Celsius
ShortLegend[localhost.temp]: C
LegendI[localhost.temp]: HDD Temperature
LegendO[localhost.temp]: Sys Temperature

### Memory

Target[localhost.mem]: hrStorageUsed.1&hrStorageUsed.1:public@localhost * 1024
Title[localhost.mem]: Memory Consumption
PageTop[localhost.mem]:Memory Consumption

Options[localhost.mem]: growright,gauge,nopercent,noo,transparent,nolegend,nobanner,noborder

MaxBytes[localhost.mem]: 129871873
LegendI[localhost.mem]: Used Memory
ShortLegend[localhost.mem]: Bytes
Unscaled[localhost.mem]: ymwd
YLegend[localhost.mem]: Bytes
Kilo[localhost.mem]: 1024

### Hard drive: /
Target[localhost.hd1]: hrStorageUsed.31&hrStorageUsed.31:public@localhost * 4096
Title[localhost.hd1]: Disk Usage: / 
PageTop[localhost.hd1]:Disk Usage: /

Options[localhost.hd1]: growright,gauge,nopercent,noo,transparent,nolegend,nobanner,noborder

MaxBytes[localhost.hd1]: 100000000000000000
LegendI[localhost.hd1]: Storage Used
### LegendO[localhost.hd1]: Total
Kilo[localhost.hd1]: 1024
YLegend[localhost.hd1]: Used Bytes
ShortLegend[localhost.hd1]: B
       
There are some important notes however:

• Hard disk usage is normalized against the 1TB version of the MBWE. The corresponding MaxBytes property  has to be modified if this is to be used with a hard disk of an other size.
• The global RouterUpTime property is modified so that it indeed reflects the uptime and not just the uptime of the net-snmp daemon.
• Memory usage is set to plot against the maximum of 128 MB for the white light edition. For the blue ring edition 64MB is to be used.
• If the script for temperature reading is put somewhere else, the corresponding Target line has to be altered as well.

In case everything is OK, which can be tested by manually issuing ´mrtg /opt/etc/mrtg.cfg´ in the shell, the other graphs are filled with data as well:

WD MyBook Hacks - Temperature Readings

This is a topic that puzzled me for some time. Built-in temperature sensors are useful for monitoring the health status of the device and making proper action if for instance overheating occurs. For personal computing, lm-sensors is a frequently-used tool for this purpose which is able to read the sensors via SMBus on most of the motherboards. However, the MyBook has a different facility for this, so we will see how to take advantage of it. In fact, not only the on-board temperature sensor can be read, but the one on the hard drive can be used as well.

Reading sensor on the hard drive

This sensor can simply be reached through reading the S.M.A.R.T. data of the drive as I posted earlier. What we need to do is to grep the useful data and get rid of the garbage by selecting the line and the field we are interested in:

#~: smartctl -a -d ata /dev/sda | awk '/Temperature/ {print $10}'

44

will do the job, and we get the temperature of the hard drive in Celsius.

Reading the on-board temperature sensor

This one can be interrogated through:

#~: cat /sys/module/thermAndFan/parameters/current_temp

27

which is a reasonable value. If however we look further into the details:

#~: cat /sys/module/thermAndFan/parameters/hot_limit

16

#~: cat /sys/module/thermAndFan/parameters/cold_limit

104

this should give the clue that this is not a direct temperature reading. Indeed this sensor does not read in Celsius but rather in "Counts" which is proportional to the sensor resistance value. Luckily enough google finds the lookup table for this platform here (see TvsCnt[] array). As the sensor is a semiconductor thermistor, there is no simple linear equation to determine the temperature, rather the following exponential dependence should be used: Cnt=a×exp(b/T), with Cnt being the reading above and T being the absolute temperature in Kelvin. For this specific sensor the parameters are a=1/9331 and b=3865 as a result by a simple fitting procedure. So after some algebra we find that the temperature will be: t=3865/(ln(Cnt)+9.1411)-273.16 in Celsius (feel free to do it in Fahrenheit :) ).

In order to implement this equation, we will use the command-line calc tool:

#~: ipkg install calc

Finally using this tool a simple script can be used to determine the temperature:

#!/bin/sh

Y1=`cat /sys/module/thermAndFan/parameters/current_temp `

C1='display(0);config("tilde","off");3865/(ln('
C2=')+9.1411)-273.16'
/opt/bin/calc $C1$Y1$C2 | awk 'NR==3 {print $1}'  

which results in a single return value, e. g. 37.

Finally the question remains: Why would we do this? The reason is that these readings can be plotted using for instance MRTG, so that the health status of the storage can be checked easily.

WD MyBook Hacks - Remove Default Shares

The default shares - [Download] and [Public] - always annoyed me quite a lot, so I figured out how to remove them, since simply deleting them obviously won't work:

1. stop samba daemon: #~: /etc/init.d/S90smbd stop
2. edit /usr/private/user_smb_conf/.overall_share:  remove sections [Download] and [Public] (should be first two sections). Note: Here you can also check the other shares manually.
3. start samba daemon: #~: /etc/init.d/S90smbd start

Well, that's all. It is also possible to make a backup copy of .overall_share so that it can be restored if necessary since we did not delete the actual directories.
Update: the web interface seems to overwrite .overall_share adding the removed sections always if a new user is added or user credentials are changed. The obvious yet inconvenient solution is to do this hack every time it is necessary, while the proper solution would be to alter the corresponding part of the web interface. This I haven't figured out yet, but I will post it if I succeed.

WD MyBook Hacks - Built-in Webserver

Apparently the white light version of MBWE broke up with lighttpd, and hooked up with mini_httpd. Reason for this is unknown for me, one thing is sure however: If you want to be on the safe side and use the web-based admin interface, it is better to live with it. I do believe that other http servers can be installed, including:

~#: ipkg list | grep httpd

lighttpd - 1.4.25-1 - A fast webserver with minimal memory footprint.
minihttpd - 1.19-2 - small HTTP server
nostromo - 1.9-1 - nhttpd is a simple, fast and secure HTTP server.
php-thttpd - 2.25b-5.2.12-1 - php-thttpd is thttpd webserver with php support
thttpd - 2.25b-5 - thttpd is a lightweight http server

Each has a separate way to configure, the only thing that has to be made sure is that it binds to a different port than the default 80. Or, even better the admin interface can be removed from port 80, by using -p command-line parameter discussed later on.

Anyhow, at the moment we deal with the mini_httpd:

~#: ps ax | grep http

 2566 root        832 S < /usr/sbin/mini_httpd -d /proto/SxM_webui -c **.mp3|**
16981 root        584 S   grep http

which tells us that the served directory is /proto/SxM_webui. This means that additional files or directories created there will be served as well by the daemon so it is suitable for share simple things not including password protection, virtual hosts and so on...

In fact, I did not find any reasonable online manual page for mini_httpd, yet its basic features are easy to find:

~#: mini_httpd --help

usage:  mini_httpd [-C configfile] [-D] [-S] [-E certfile] [-Y cipher] [-p port] [-d dir] [-dd data_dir] [-c cgipat] [-u user] [-h hostname] [-r] [-v] [-l logfile] [-i pidfile] [-T charset] [-P P3P] [-M maxage] [-maxproc max_concurrent_procs]

On my system /etc/init.d/S55mini_httpd starts the server with the following syntax:

/bin/nice -n -20 \
    /usr/sbin/mini_httpd \
    -d $WEBROOT \
    -c "**.mp3|**.m4a|**.mp4|**.mov|**.pdf|**.wma|**.m4v|**.php|**.cgi" \
    -u root \
    -l /var/log/mini_httpd.log \
    -i /var/run/mini_httpd.pid \
    -maxproc 16 \
    -p $HTTP_PORT

with $WEBROOT being just as above and $HTTP_PORT = "80".

WD MyBook Hacks - Print Server

There are a plenty of tutorials on web on this topic, yet none of them worked for me out of the box, so I put   together this guide with steps that worked for me (mostly based on this and this tutorial).

The printer was a HP Laserjet 2300L equipped with USB connection only. Upon connecting the printer to the storage I encountered the first issue:

~#: lsusb

had no output at all. However

~#: cat /sys/bus/usb/devices/1-1/product

hp Laserjet 2300L

revealed that the printer is indeed there so that there is no hardware problem.

What we need first of all is the following:

 ~#: mount -t usbfs none /proc/bus/usb   

so that lsusb will be able to list devices. CUPS is ready to roll now:

~#: ipkg install cups cups-doc cups-driver-gutenprint cups-pdf hpijs

will install CUPS version 1.4.2 and HP printer device drivers.

Contrary to earlier versions in the package repository,  this one works well so no recompile is necessary (so the presence of gcc is not required). The web interface of CUPS will be available at http://IP_of_NAS:631. Since for /admin https is required (and is a good practice anyhow), we still need to create the proper ssl certificate since this automatism fails for some reason:

~#: openssl req -new -x509 -keyout /opt/etc/cups/ssl/server.key -out
/opt/etc/cups/ssl/server.crt -days 365 -nodes -config /opt/share/openssl/openssl.cnf

and then:

~#: cupsd

starts the daemon itself. We still lack the USB printing support which should be available as a kernel modul. This I found here (great thanks for Bertram Winter!). This should be put to the following directory:

/lib/modules/2.6.24.4/kernel/drivers/usb/class/. This can be easily achieved by issuing:

~#: mkdir /lib/modules/2.6.24.4/kernel/drivers/usb/class/

~#: wget http://members.aon.at/berwinter/mbwe/usblp.ko.whitelight -O /lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko

Don't forget to create the corresponding node!

~#: mknod /dev/lp0 c 180 0

So the modul is ready to be loaded:

~#: insmod /lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko

It worth a note that even though /dev/usb/lp0 exists, still /dev/lp0 has to be used.

So now we have three USB related moduls:

~#: lsmod | grep usb

usblp                  12064  0

usb_storage            35936  0

usbcore               120212  4 usblp,ehci_hcd,usb_storage

We can also test whether CUPS also sees what needs to be seen:

#:/opt/lib/cups/backend/usb 

DEBUG: list_devices

DEBUG: usb_find_busses=1

DEBUG: usb_find_devices=2

Now we can add the printer on the web interface: https://IP_of_NAS:631/admin

Login/pass are the root credentials. The printer should be visible after choosing "Find New Printer". The rest is quite self-explaining, I chose the corresponding HP Laserjet 2300 PS driver. Note: the "Share Printer" checkbox should be checked! Most of the default options are OK, only paper size has to be changed to A4 (at least in Europe ;)). Some fine tuning includes reduce of maximum amount of jobs and clients as this one is anyhow an embedded system. For this, refer to the following screenshot:

Now the printer should be visible if pressing "Manage Printers":

For the clients the printer will be available as: https://IP_of_NAS/printers/name_of_printer. In Windows one simply has to press Add Printer, choose Network Printer and provide the above address. As for printer driver, Generic -> MS Publisher Imagesetter works well:

It worth a note that here we chose to use the specific driver in CUPS, and issued the client to use a generic (postscript) driver. It can be done in the other way around as well: in that case Raw driver has to be chosen when adding the printer on the server and the specific driver has to be installed on the client.

At this point the only remaining task is to have all of these persistent, so have the CUPS daemon started when the device boots up. For this I made the following script based on this one:

#!/bin/sh

MODULE=/lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko
LPNODE=/dev/lp0
CUPSD=/opt/sbin/cupsd
SETUP=/opt/sbin/lpadmin
PRINTER="LaserJet_2300L"

case "$1" in
        start)
                if ( [ ! -c /dev/lp0 ] ) then
                        mknod $LPNODE c 180 0
                fi
                #/bin/chown sys:lp /dev/lp0

                if ( !(lsmod | grep "^usblp" -q) ); then
                         insmod $MODULE
                fi

                if [ -n "`pidof cupsd`" ]; then
                        /usr/bin/killall cupsd 2>/dev/null
                fi
        $CUPSD
        $SETUP -p $PRINTER -E
        ;;
        stop)
                if [ -n "`pidof cupsd`" ]; then
                        /usr/bin/killall cupsd 2>/dev/null
                fi
        ;;
        *)
                echo "Usage: (start|stop)"
                exit 1
esac

The script first makes sure that the device node exists and the module is loaded (the rest of the usb modules are anyhow loaded on startup). Then kills all instances of the daemon before starting the new process. Note that the printer has to be specifically enabled by lpadmin -p "printer name" -E which is done just after the daemon started.

WD MyBook Hacks - S.M.A.R.T.

There was something that bothered me quite a lot: while the MyBook seems to have smartmontools preinstalled, I was not able to read SMART data from the hard disk:

~#:smartctl -a /dev/sda

smartctl version 5.38 [arm-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: WDC      WDC WD10EADS-00L Version: 01.0
Serial number:      WD-WCAU4C518954
Device type: disk
Local Time is: Wed Dec 30 16:23:35 2009 CET
Device does not support SMART

Error Counter logging not supported

[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
Device does not support Self Test logging

This is strange because 3.5" SATA drives supposed to possess SMART capability. After reading the smartmontools wiki through I came up with the solution:

 ~#:smartctl -d sat -a /dev/sda

an additional "-d sat" parameter is necessary for proper operation. I note however that "-d ata" works as well. In the output we have the table that should look like something like this:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   157   156   021    Pre-fail  Always       -       7116
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       53
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       171
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       11
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       4
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       53
194 Temperature_Celsius     0x0022   111   100   000    Old_age   Always       -       39
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

For detailed explanation of the parameters above I suggest reading the corresponding Wikipedia article.

WD MyBook Hacks - LEDs

One fascinating aspect of this storage device is the front LED panel. This can be used to visualize the status of the MyBook, or even to merely play around :)

For the "blue ring" version of the MyBook there exist a detailed tutorial on the related wiki, yet for the newer "white light" version I haven't found anything, but after some testing I managed to have a consistent picture of what is going on. Let's see:

The modul in charge for operating the LEDs is the following:

~#: lsmod | grep led

oxnas_wd810_leds            7496   0

This modul is located in  
/lib/modules/2.6.24.4/kernel/arch/arm/mach-oxnas/oxnas-wd810-leds.ko.

 If the modul is loaded (it should be on startup), we get the interface in /sys/class/leds:

/sys/class/leds#: ls -1

oxnas-wd810-leds:ac/

oxnas-wd810-leds:ca/
oxnas-wd810-leds:st/
oxnas-wd810-leds:sw/

Here we find for directories with rather identical content:

/sys/class/leds/oxnas-wd810-leds:ac#: ls -1

brightness
device@
subsystem@
trigger
uevent 

In detail:

brightness contains a single numeric value between 0 and 255
device@  symlink to /sys/devices/platform/oxnas-wd810-leds directory
subsystem@ symlink to /sys/class/leds
trigger:  by default one single line: none [sata-disk]
uevent: contains:

PHYSDEVPATH=/devices/platform/oxnas-wd810-leds

PHYSDEVBUS=platform

PHYSDEVDRIVER=oxnas-wd810-leds

Out of these brightness will be of the most importance. Using the numeric value here we can control the illumination of the LEDs. The rest, well those need some more research, I think however that it is a good idea to leave uevent alone, and trigger might be responsable of the automated operation in response to some event. It is quite confusing still that it has the same content in all four directiories...

The brightness files can simply be altered by for example:

/sys/class/leds/oxnas-wd810-leds:ac#: echo 1 > brightness

which means that we put "1" in the file. So let's see the role of each directory:

• oxnas-wd810-leds:ac/: "ac" might stand for activity. Putting any numeric value here will cause the LED stripe sweeping up and down once and returning to the previous state. It is interesting that the actual value does not matter (even can be the same always), yet a simple "touch brightness" is not enough.
• oxnas-wd810-leds:ca/: Here we have a fuel gauge operation of the stripe. The numeric value expresses percentage, so that values between 0 and 100 make sense here. 
•  oxnas-wd810-leds:st/: This directory is for several visual effects (including blinking, wobbling, sweeping back and forth...) which can be altered by putting a number between 0 and 15 in the brightness file. Larger values have no effect, while 0 and 1 stand for the steady pattern determined by the fuel gauge.
• oxnas-wd810-leds:sw/ I did not manage to alter the LED pattern by any numeric value. This can be either not implemented feature or has some different mode of operation.

Using these one can easily visualize the disk usage, temperature, or even the load average of the MyBook :) The moving patterns are also capable of some sort of alarm operation (based on e. g. SMART report of smartmontools).

I noticed that sometimes all of the LEDs turned off and didn't respond anymore. In this case a reboot is necessary since reloading the module itself not seemed to be enough.

There is even more: I also found signs of controlling the rest of the LEDs on the storage (including power, USB). This is what I found in /sbin/fschk_prompt.sh:

    #Turn on PWR LED

    /bin/echo 0 >/proc/wixgpio/gpio06

    #Turn off PWR LED

    /bin/echo 1 >/proc/wixgpio/gpio06

    #Turn on USB LED

    /bin/echo 1 >/proc/wixgpio/gpio10

    #Turn off USB LED

    /bin/echo 0 >/proc/wixgpio/gpio10

    #Turn off ID LED

    /bin/echo 0 >/proc/wixgpio/gpio00

The interesting thing is that there is neither such directory in /proc nor any GPIO-related module anywhere. So this can be some sort of residual of code from the "blue ring" device or something like that...

WD MyBook Hacks - The Basics

I recently started to play around with a 1 TB Western Digital MyBook. The aim is to make a versatile online storage and backup solution. I also found that this device can be used as a print server as well which is a plus that we might put to the test later on.

Here I will collect basic knowledge on the device as well a startup guide, while specific hacks will come later on. For putting this post together I highly relied on this wikidot page. I however decided the collect things here because sometimes I felt lost in the huge amount of wiki articles and forum posts and also some hacks are a matter of personal taste.

Upon hooking up the device on the local network, it usually gets IP address by the means of DHCP. It is recommended to supply it with a fixed IP afterward which can be achieved with most of the SOHO routers. If you want to reach the storage from outside of your LAN then it is also necessary to set up a portforward on the router for which you have to refer to the manual of the specific router or the iptables manual.

If the device is on the network, basic settings can be achieved on the web interface by simply putting the IP address of the storage to the address bar of the browser. The default login is "admin/admin". Most of the interesting stuff can be found in Advanced mode :)

I suggest to acquire the latest firmware (web update button) and both disable and unregister Mionet service. The later would be some tool for sharing remote data (except for anything that has an extension of avi, mp3...) but there are way more versatile tools for that including FTP, SFTP rendering this one useless. EDIT: it seems that simply disabling the service on the web interface is not enough. In fact, it periodically respawns. So what needs to be done is the following: From /etc/init.d remove S9M_ionet script, which starts the service upon boot.

In fact, this is not enough either, so the files /usr/mionet/changeNotifySocket and /usr/mionet/bin/cvm also need to be removed or renamed to something else.

Later on we will need to use SSH for customizing the device for which one needs either putty (for Win) or ssh for linux. For the first login the root password is "welc0me" which I strongly suggest to change immediately with the passwd command.

Next, the ipkg package management system needs to be installed. The tutorial can be found here. This lightweight package manager will give us the opportunity to get several hundreds of precompiled packages. One can also compile packages upon installing gcc, but this is way more inconvenient and usually is unnecessary.

Must have ipkg packages:

• bash (3.2.49-1_arm). Note: for effectively using bash, the shell in /etc/passwd has to be rewritten for each user from /bin/sh to /opt/bin/bash.

• bash-completion (1.1-1_arm)

• pciutils (3.0.0-1)

• usbutils (0.73-3)

• libusb (0.1.12-1)

• mc (4.6.2-1) Note: in order to preserve options, create .mc directory in ~. Further tuning includes e. g. coloring.

As ipkg installs everything in /opt, /opt/bin has to be included to the $PATH variable in /opt/etc/profile. For root, one has to include both /opt/bin and /opt/sbin to $PATH in /root/.bashrc and /root/bash_profile. Note: this applies for ipkg itself so in advance of doing so, /opt/bin/ipkg has to be used instead of simply ipkg.

Disabling Twonky Media Server is also a good idea: Like Mionet, it also consumes a great deal of memory and yet not that useful. In fact, instead of a streaming media server, one could always use file sharing and play media on the computer. Obviously this does not apply to consoles and similar stuff.  In order to permanently kill it, I simply renamed the script that starts the service upon boot:

#~: cd /etc/init.d

#~: mv S97twonkyserver /root/S97twonkyserver.old

#~: touch S97twonkyserver

#~: chmod a+x S97twonkyserver

This way we preserved the old startup script in case we need it later on and created a new placeholder file which simply will not do anything. Note that the old script has to be removed from /etc/init.d, otherwise it will run as well.

This was some sort of "must have" part, for specific hacks see the following links (continuously updated):

1. LED interface
2. S.M.A.R.T. capability
3. Print Server
4. Removing default folder shares
5. Reading temperature sensors 
6. Using MRTG