Tuesday, December 14, 2010

Quality & stability

Some followers as well as myself have noticed that this box doesn't seem to be top-notch in terms of stability. It's not too bad for me (actually, mine's been up for 75days straight) but you'd expect this thing to behave reliably, even if it is relatively cheap. Heck, my log files even don't show crazy stuff (apart from a runaway cron-ntp script running every minute?).

On the occasions that it goes in Nirvana-mode, it seems to only take a full power cycle by pulling the cord which isn't desirable for the obvious reasons (potential data loss etc.). I haven't been able to nail down the reasons for it going all unresponsive, perhaps it's heat, perhaps it's load (and because of that - running out of memory?). To address one of the comments - turning it off normally involves holding the power button for a few seconds which will initiate the power-down sequence.

I don't use the BitTorrent-client on the box since I can't stand the interface. It would have been nice if something like Transmission Remote GUI would have been usable with the box but the default btpd client doesn't accept a TCP socket connection. I've toyed with the idea of creating a TCP-to-Unix Domain Socket bridge for this puppy, but I discarded that for some reason.

Oh, the picture frame died a mysterious death - need to see whether I can get it replaced under warranty.

Apologies to the followers

Man, have I been daft.. Being all cool by creating a blog about hacking a NAS and then completely missing that people are following it and actually commenting! My apologies to those who wrote and provided suggestions and comments!

Tuesday, September 28, 2010

What about that picture frame?

Well, it's been a while, but the MD253 is still being put to good use. Actually, since we switched ISP, I changed the home network configuration a bit and suddenly throughput to the box is much better (as well as overall stability of the net connection - but that's another story).

Quite some time ago, we bought a Samsung SPF-83V picture frame. Nice high res, sparkling colors and not unimportantly: the bloody thing has WiFi support. Since I'm lazy by nature and hence don't like to be swapping memory cards each and every time I want some new pics (which we make quite a lot since our son is born) on the thing, this is great. The picture frame has two options: getting pictures from Windows Live or some other place, but fortunately, it will work just perfectly if you feed it any page with pictures. So, here's what I did, I pointed the picture frame's web address to a script I put in the MD253's /home/web/cgi-bin directory (http://SitecomNas/cgi-bin/webalbum.cgi).

The script I use randomly selects a bunch of pictures from all the pictures we put on a share:

echo "Expires: Mon, 26 Jul 1990 05:00:00 GMT"
echo -n "Last-Modified: "
date +"%a, %d %b %Y %X GMT"
echo "Cache-Control: no-store, no-cache, must-revalidate"
echo "Pragma: no-cache"
echo "Content-type: text/html"
echo ""
echo ""
echo "<HTML><HEAD><TITLE>Web album</TITLE></HEAD><BODY>"


# Clean up
rm -rf $PCACHE
rm -rf $TFILE

# Get list of files
find $SOURCE_PATH -type f > $PCACHE

# Adorn & sort
for i in `cat $PCACHE`; do
  echo $RANDOM $i >> $TFILE

# Sort, clean up
sort $TFILE | sed -e 's/^[0-9]* //' | head -n $MAX_PICS > $PCACHE

# Ok, output
for i in `cat $PCACHE`; do
  fn=`echo $i | sed 's/\/home//'`
  echo "<img src=\"$fn\" />"

echo "</BODY></HTML>"

Not perfect, not anywhere near rocket science (although...), but it works like a charm. Fresh pics every day!

Wednesday, April 7, 2010

Filesystem.bin Squashfs-lzma update

Good. Using version 3 of the GRML version of squashfs-tools, I managed to unpack filesystem.bin. Grab the tools at http://deb.grml.org/pool/main/s/squashfs-lzma/

# /usr/bin/unsquashfs -f filesystem.bin

created 206 files
created 20 directories
created 197 symlinks
created 0 devices
created 0 fifos

Content is in a sub-directory squashfs-root in the current directory.

Filesystem.bin Squashfs-lzma

After some hunting the net, I found some prebuilt tools for handling squashfs images that are compressed using the LZMA method. This method is by default not supported in squashfstools and building requires some heaving rain dances.

Using the squashfs-tools-lzma 4 package from grml.org, and doing a unsquashfs-lzma -s filesystem.bin, you get:

Found a valid little endian SQUASHFS 3:1 superblock on filesystem.bin.
Creation or last append time Wed Feb  3 04:08:29 2010
Filesystem is exportable via NFS
Inodes are uncompressed
Data is compressed
Check data is not present in the filesystem
Fragments are not present in the filesystem
Always_use_fragments option is not specified
Duplicates are removed
Filesystem size 5012.55 Kbytes (4.90 Mbytes)
Block size 1048576
Number of fragments 0
Number of inodes 423
Number of uids 1
Number of gids 0

Initially, unsquashfs fails with
Can't find a SQUASHFS superblock on filesystem.bin

This seems to be due to incorrect header magic (shsq), if changed to hsqs, unsquashfs-lzma is happy (so far). Trying to extract files only succeeds partially, complaining about unknown errors -3 and that it cannot create certain files. Possibly, this has to do with different versions or patches of the unsquashfs-lzma tools.

Tuesday, April 6, 2010

Bricking issue solved?

According to a guy at http://tweakers.net/productreview/17387/sitecom-md-253.html (dutch forum), the reason for bricking should have been resolved in the latest firmware. I can't recall anything from looking through the *27 firmware that gave me impression that this would be the case, but it has been a few weeks, so I'll have to see what has happened there.

By the way: the filesystem.bin seems to be a SquashFS image that has been compressed using the LZMA method which requires special tools to inspect (and kernel support if you want to mount it).

Monday, March 22, 2010

Firmware 2.3.27 is out

After I noticed that firmware 2.3.24 was pulled from the SiteCom site, I just noticed tonight that there is a new version up on the web site: 2.3.27. No idea yet what it fixes or whether it will break/brick anything. If you used any of the tricks in the posts below, be careful.

A quick check of the cgi-bin scripts shows that it should still be possible to remotely enable the SSH-service. Doing a diff of bootfs.bin shows mainly a number of SMB-related changes (mentioning the host name here and there), some tweaks to the web UI and changes to mounting /dev/mtdblock3 as /dev/ram1. Also, /proc is no longer mounted by default.

Still need to check out filesystem.bin