Blocking access to DD-WRT’s web interface from guest network

Even though I’ve shifted all the routing functionality of my LAN to the excellent pfSense (and specifically to a PC Engines alix2d2, for the time being), DD-WRT still plays a role in my network, since it powers a couple of my access points.


One of its key features that I rely on is the ability to make two or more SSIDs available, bridging the wireless networks to different VLANs in order to separate them. I have a couple of them at the moment, but the main “secondary” network is the guest one.

On my guest network, I want to prevent any access to DD-WRT (such as the web interface, SSH management, and so on). AFAIK, there’s no graphical way to do so in the admin panel, so I resorted to a quick iptables rule.

iptables -I INPUT -i br1 -d <DD-WRT's IP on guest net here> -j DROP

Basically this tells the firewall to DROP every packet that comes in from the br1 interface (make sure it’s the correct one in your config) and that is destined to its IP address on that interface.

To save and apply this rule log into the web interface, go to Administration/Commands, paste the command above (make sure you’ve inserted the correct IP) and then click on the “Save Firewall” button. Done.

Note: with this rule DD-WRT will be unreachable from that VLAN/SSID, even to you, so you’ll always have to access it from the main VLAN/network.

Automatically download iOS firmwares


Today I discovered that it takes quite a while to download an iOS IPSW, and when you need IPSWs, you are always in a hurry. So I made this little script that checks for a new release using’s API and downloads it. The comments in the script itself should make it pretty easy to use.

I added the script to my home server’s crontab, and scheduled it to run at 1 am every night, with a low bandwidth limit not to hog my connection.

Note: to use this on OS X you will have to either install wget (from sources, binaries, brew, ports, whatever) or edit the script to use curl.

What I learned about the current state of XBMC and Broadcom Crystal HD

In the last couple days I experimented a little with an old crappy laptop I had lying around for a while. I wanted to use it as a media center, but it was too old to support h264 hardware decoding, so playing 1080p content was basically impossible. So I bought a Broadcom BCM970012 Crystal HD hardware decoder for less than 20 euros on Amazon.

Broadcom Crystal HDThis little Mini PCI-E card handles the video decoding in hardware, and does so very efficiently, drawing almost no power. It became famous to enable 1080p on the 1st-gen Apple TV, which funnily enough has the same crappy GPU I have on my old laptop, an Nvidia GeForce Go 7300.

Broadcom is not supporting this card anymore, with the latest Linux driver available released in 2010. Anyway, I managed to get it working on XBMC 13.1 Gotham running on Debian Wheezy (7.0).

Getting the hardware to work

The first thing to note is that you have to run a 32 bit OS to be able to use this card reliably. I tried to use it on 64 bit installs of both Debian and Ubuntu, with no luck.

Second, support for Crystal HD will be dropped by Kodi (née XBMC) version 14.

Given this assumptions, I’ll briefly outline what was needed to get it to work.

First, I installed Debian. I opted for a net-install, in order to carefully choose only the packages I really needed. The laptop was quite old, so I didn’t want to bog it down with stuff I ultimately didn’t need. I went through the usual dance to install Nvidia’s proprietary drivers (version 304.x, since this is a legacy GPU), and installed alsa-utils in order to enable audio.

Debian doesn’t ship with the required crystalhd kernel module, so I had to compile my own. It was pretty easy (kernel 3.2.0-4-686-pae), I just followed the first part of this guide. Just in case it should disappear from the internet, I took the liberty to upload the source code here, and copy the required steps below:

  1. Install the required dependencies
    sudo apt-get install git automake g++ build-essential linux-headers
  2. Compile the driver
    cd crystalhd/driver/linux
    sudo make install
  3. Compile the library
    cd ../../linux_lib/libcrystalhd/
    sudo make install
  4. Load the driver
    sudo mod probe crystalhd

If all went as it should, you now have a working kernel module for Crystal HD cards.

In Debian Wheezy’s repos, you will find a really old version of XBMC (version 11). It will work, but I always prefer to have the latest stable version of everything. I dug around a bit, and found that in the official wheezy-backports repo there was a fairly recent Gotham release, 13.1RC1. I could have compiled a newer one, but it would have been more trouble than what it’s worth. So I went and added the repo to my sources.list, and installed the version from the repo.

echo "deb wheezy-backports main contrib non-free" | sudo tee -a /etc/apt/sources.list
echo "deb-src wheezy-backports main contrib non-free" | sudo tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get -t wheezy-backports install xbmc

That’s it, Crystal HD decoding should now work without further actions.

The only thing was that it stopped working after waking from sleep. The solution was easy: save this script as /etc/pm/sleep.d/80crystalhd and make it executable with sudo chmod +x /etc/pm/sleep.d/80crystalhd.

case $1 in
        echo "Hey guy, we are going to suspend to disk!"
        modprobe -r crystalhd
        echo "Oh, this time we're doing a suspend to RAM. Cool!"
        modprobe -r crystalhd
        echo "oh, suspend to disk is over, we are resuming..."
        modprobe crystalhd
        echo "hey, the suspend to RAM seems to be over..."
        modprobe crystalhd
    *)  echo "somebody is calling me totally wrong."

What this does, is it unloads the kernel module before suspending/hibernating and reloads it when the system wakes up. I didn’t think it would work even with XBMC still running, but it did.

Final touches

I then focused on cleaning up the experience of using XBMC:

  • It should launch automatically at boot time
  • It should be possibile to sleep/shutdown/restart from XBMC without needing the root password
  • The system should wake up on any USB activity

Autostart at boot

To launch XBMC at boot time you have to put a .xinitrc file in the home directory of XBMC’s user (from now on, I’ll assume that it’s xbmc, which makes sense).


Then, save this in /etc/init.d/xbmc and make it executable (sudo chmod +x /etc/init.d/xbmc)

# Provides:          xbmc
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts instance of XBMC
# Description:       starts instance of XBMC using start-stop-daemon and xinit
############### EDIT ME ##################
# path to xinit exec
# startup args
#DAEMON_OPTS=" /usr/local/bin/xbmc --standalone -- :0"
# script name
# app name
# user
# Path of the PID file
############### END EDIT ME ##################
test -x $DAEMON || exit 0
set -e
case "$1" in
        echo "Starting $DESC"
        start-stop-daemon --start -c $RUN_AS --background --pidfile $PID_FILE  --make-pidfile --exec $DAEMON -- $DAEMON_OPTS
        echo "Stopping $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE
        echo "Restarting $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE
        sleep 5
        start-stop-daemon --start -c $RUN_AS --background --pidfile $PID_FILE  --make-pidfile --exec $DAEMON -- $DAEMON_OPTS
        echo "Usage: $N {start|stop|restart|force-reload}" &gt;&amp;2
        exit 1
exit 0

Then, make it start at boot:

sudo update-rc.d xbmc defaults

Allow shutdown/sleep/reboot from XBMC

To do so, you need a “policy” file. Save this to /etc/polkit-1/localauthority/50-local.d/custom-actions.pkla

[Actions for xbmc user]

Allow wake from any USB peripheral

Add this line to /etc/, just before exit 0, and make it executable (chmod +x /etc/rc.local)

echo enabled | tee  /sys/bus/usb/devices/*/power/wakeup


I may have forgotten something while writing this post. What I definitely forgot is when I needed to reboot to apply this changes. I know it is a very Windows-y thing to do, but reboot if things don’t seem to work.

Record and archive video from IP cameras

I’ve had a couple of Foscam FI9805W H264 IP cameras for almost a year, and I’ve been very happy with them: the 1280×960 image is sharp and clear both during the day and during the night, and their firmware has been very reliable.


One thing I wanted, though, was having the footage from the last 1-7 days available at any time. The onboard firmware allows to record to an FTP server, but this was suboptimal, there was no easy way to define the clip length and was pretty clunky to set up.

I started digging around, and I found that ffmpeg could easily record the RTSP stream from the cameras. In the cameras’ settings you can choose the video bitrate, up to 4 Mbit. I found that the optimal bitrate is 2 Mbit: going to 4 only meant that the files were twice the size without any noticeable improvement of the quality.
This results in approximately 15 Gb per day per camera of video files. This is way lower than 2 Mbit average, and that’s due to the fact that during the night, with the IR lights on, the image turns to black and white and the bitrate lowers to about half of the usual value.

I came up with a complete solution which is made of the following parts:

  • Two Foscam FI9805W IP cameras, but any reasonable number of cams can be used
  • My home server, running Debian, which is on 24/7
  • A cronjob that fires up ffmpeg every 15 minutes to record 15 minutes clips. This makes searching much easier than having to deal with giant multi-hour recordings.
  • A cronjob that triggers everyday at midnight, which converts recordings older than 24 hours to a much smaller low-framerate and low-quality files to reduce disk usage
  • A cronjob that triggers everyday at 4 am to purge older recordings.

Recording video

This is the easy part. I just use this script, which I named

You’ll have to edit the IP address, port number and login credentials to suit your needs and add/remove additional lines at the bottom to match the number of cameras you need to record. Also, set your own paths.

You need to add a cronjob to your system, to fire this script every 15 minutes:

*/15 * * * * /path/to/

Quick tip: in the settings of each of your cameras, add a “Visitor” type user for esclusive use in this script, so that if somebody finds its password (which as you can see is saved in the clear) he cannot mess up with your cameras’ settings.

Converting to low-quality for archival

I decided I don’t need to save full-quality recordings of every single second, so my compromise was to heavily re-compress videos older than 24 hours (1440 minutes).

After lots of tests, I chose to reduce the framerate from 30 to 5 fps and set the bitrate to 100 kbits. That’s a really low bitrate for 960p videos, but since the footage is mostly static the quality is still half decent. The space usage is about 1 GB per day per camera.

The script I use,, is this:

It takes the file you pass to it, creates the appropriate folder structure and encodes it, then it deletes the original file.

This is the cronjob that launches the script:

0 0 * * * find /path/to/surveillance/folder/video/ -mmin +1440 -size +10000k -exec /path/to/ {} \;

I use the find command to get the videos that need to be converted, and it looks for files over 10 megabytes that were last modified more than 1440 minutes ago. Of course, you are free to change these parameters as you wish.

Pruning old videos

Even with this heavy compression, the files add up quickly, so I decided it’s not worth keeping videos older than a week.

So, here is the cronjob to do the job (pun intended):

0 4 * * * find /path/to/surveillance/folder/archive -mindepth 3 -type d -mtime +5 -exec rm -r {} \;

It looks into the archive folders, looking for directories, as each day has its own, older than 5 days (that’s a weird side effect of confusing date math: you’ll end up having 7 days worth of recordings, plus the high quality last day).

The -mindepth 3 parameter was required due to the folder structure I chose, which is: archive/camXX/YYYY-MM/DD/*.mp4

  • At the first depth level there are the folders of each camera. Their last-modified date changes every time you add or remove a file/foder inside it, so this actually happens the 1st of evert month, when the month’s folder is created.
  • At the second level, there are the YYYY-MM folders, so we shouldn’t touch them
  • Finally, at the third level there are our “day” folders, which we want to delete when they get too old.

Then a final cronjob that removes old and empty month directories

1 4 * * * find /path/to/surveillance/folder/archive -mindepth 2 -maxdepth 2 -type d -empty -exec rmdir {} \;

You’re done

Yes. That’s it. I admit it’s not very straightforward, but it does work once all the pieces are in place. The nice thing is that all the mp4 files, both those saved directly from the cameras and the re-encoded ones play nicely on my iOS devices (I presume Android as well, but I don’t have a device handy to test), so I can just VPN back home to retrive a recording, should I need to.

If you have any questions feel free to leave a comment below, I’ll try to reply to everyone.

Avoid stuttering streaming from NFS shares with XBMC on the Raspberry Pi

I’ve been using my Raspberry Pi with XBMC (using the awesome Raspbmc distro) for a while now, I even control it using my CEC-Compatible HDTV’s remote, but I pretty much always experienced stuttering while playing 1080p videos streaming from my home server, which was mounted on the Pi via NFS (directly through its /etc/fstab).Raspberry XBMCI dismissed the issue telling myself “it’s just not powerful enough”. But that’s not really the case. Not always, at least.

A little background

The Pi has an onboard GPU capable of decoding 1080p H.264 video, but it has no hardware acceleration for audio, which often leads to issues. DTS and AC3 often are difficult beasts for the board’s underpowered processor, unless you have a TV which is capable of decoding them on its own, in which case you just have to enable DTS/AC3 passthrough in XBMC’s settings.

If you quickly google “raspberry xbmc stutter”, audio tracks are often mentioned as responsible for poor playback, and it usually helps to play stereo versions of the movie sound track, if available. I convert all my movies (which generally come in the form of MKV files) using iFlicks, in order to make them iTunes and iOS-friendly. It always creates an AAC-encoded stereo track for each language, so it’s always available to help the poor ARM chip.

A solution (for me)

Still, my 1080p files stuttered, while 720p played flawlessly. Just for the sake of curiosity, I tried copying one of these movies to an USB thumbdrive, and I attached it directly to the Raspberry Pi. To my surprise, it played smoothly.

I also noticed that playing the same file over HTTP (I also have a web server running on my home server), was just as good.

So it looked like NFS was the one causing troubles. I posted on STM Labs’ (the makers of Raspbmc) forum, and I was told to try to play around with NFS mount options in my /etc/fstab, since I was probably getting an insufficient throughput that caused stuttering. Well, that did the trick. After some trial and error, here is my “magic” line that gives me a great 11,7 Mb/s speed reading files from my NAS (that’s very close to the physical limit of the Pi’s 100 Mbit port, which is more than enough even for 1:1 BluRay rips). /thor nfs udp,noatime,rsize=32768,wsize=32768,nolock,nfsvers=3 0 0

You’ll have to adjust your server address, path and mount point, but the mount parameters will likely work for you as well.


UPDATE: Andrew T suggested a better way to configure OpenELEC to mount NFS shares at boot, you will find it in the comments below this post.

As MartinP pointed out in the comments, due to OpenElec’s root filesystem being mounted read-only, editing /etc/fstab isn’t possibile.

However, it is possibile to edit /storage/.config/ to run the mount command at boot. As an example, you can edit it like this:

sleep 25
mount -t nfs /thor -o udp,noatime,rsize=32768,wsize=32768,nolock,nfsvers=3

As noted for /etc/fstab, adjust the server IP, share name and mount point as needed.

Check the headers sent by a web server using curl

If you ever wanted to easily and quickly check the headers sent by any web server you can do it with curl. It comes preinstalled in OS X as well as in many Linux distributions, and it makes this operation really straightforward.

Curl in action showing HTTP headers

Just launch

curl -I

and you’ll get every response header sent by the site. Easy, huh?

Use .rev files from the command line

Sometimes, when you download a big multi-part rar file, a part gets corrupted, or it is not even available. Often, however, .rev files are made available, and they’ll let you extract the file even with missing/corrupted parts. In fact, they let you re-create these parts, in a way similar to RAID-5/6 for hard disks.

Rar files

You can use the command line rar tool to do all the job. First, head over to rarlab, the official site, and download the appropriate version for your OS.

On Linux and OS X, you might want to move the binaries into your path, for example into /usr/bin.

Then, cd into the directory where your parts reside (together with .rev files, you need one for each damaged part you wish to recover), and launch:

rar rc yourfile-part01.rar

The rc switch tells rar to ReConstruct any missing parts (I’d advise you to move somewhere else or delete any damaged parts). Point it to part number 1, it’ll figure out the rest. The process can be quite long, more so for big archives, but it’s worth waiting. After it’s done, you can extract your files as usual, or directly using the command line:

rar x yourfile-part01.rar