OpenELEC/Kodi storage on NFS

  1. Do a normal install, boot up the system and enable ssh access.
  2. Create the file /storage/.config/systemd/storage-kodi.mount with the following contents:

    Description=Kodi NFS Storage

  3. Enable the job

    systemctl enable storage-kodi.mount

  4. Stop the current running Kodi

    systemctl stop kodi

  5. Mount and move current data, then create symlink

    mkdir /storage/kodi
    mount -t nfs /storage/kodi
    cp -vr /storage/.kodi/* /storage/kodi/
    rm -rf /storage/.kodi
    ln -sf /storage/kodi /storage/.kodi

  6. Start Kodi

    systemctl start kodi

Speaker stand of old IKEA lamp

I could drill a new hole for the cable though.

Debian on ReadyNAS Duo v2

Before the purchase I found this older teardown and HowTo, that proved that it was fully possible at least. However it was quite dated and targeted against an older Debian release. I browsed the installer files of Debian Jessie (8) and tried figure out how to apply same installation method but with a new release.

However, After a first trial install of Jessie, I noticed that the kernel (3.16.0) lacks some features (Real time clock, full Marvell CESA support etc.) I did a new test install with the upcoming Stretch (9.0) with a updated 4.9.0 kernel, and now everything seems to work.

  1. Setup a TFTP service on a host of your choice.

  2. You need to establish a bootloader serial console just as in the HowTo mentioned earlier. Beware, It's 3.3V TTL level serial.

  3. Debian unfortunally doesn't provide a ReadyNAS Duo v2 kernel image that works with the old Netgear uBoot, so we have to package our own. Grab the default kernel and the Device-Tree binary for the machine. Then stack the Device-Tree binary after the kernel image file to a new combined file.

    cat vmlinuz-4.9.0-1-marvell kirkwood-netgear_readynas_duo_v2.dtb >> vmlinuz-dtb

  4. Convert the vmlinuz-dtb image to a uboot image with mkimage

    mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n "Debian RND2 kernel" -d vmlinuz-dtb /srv/tftp/uImage-rnd2

  5. I then used the installer-initrd for the Sheevaplug ESATA witch is very smilar and should work fine for the install.

    mv uInitrd /srv/tftp/uInitrd

  6. Bring up the bootloader console (just hit any key at startup) and do the following.

    setenv autoload no
    set serverip
    tftpboot 1200000 uImage-rnd2
    tftpboot 2000000 uInitrd
    set bootargs console=ttyS0,115200 earlyprintk
    bootm 0x1200000 0x2000000

  7. You should now end up in a Debian installer. Just follow the installer as any normal install. When you are about to finish (The question of "Go back"/"Continue"), Go back and Execute shell. The chroot to the installation target.

    mount --bind /dev /target/dev
    mount -t proc none /target/proc
    mount -t sysfs none /target/sys
    chroot /target /bin/bash
    apt-get install flash-kernel

  8. Use the following machine configuration in /etc/flashkernel/db

    Machine: NETGEAR ReadyNAS Duo v2
    DTB-Id: kirkwood-netgear_readynas_duo_v2.dtb
    DTB-Append: yes
    Mtd-Kernel: uImage
    Mtd-Initrd: minirootfs
    U-Boot-Kernel-Address: 0x08000
    U-Boot-Initrd-Address: 0x0
    Required-Packages: u-boot-tools
    Bootloader-Sets-Incorrect-Root: yes
    This basically tells whenever there is a new kernel or initrd, you should also append the DTB and create uBoot compatible images, then write those to the MTD/NAND partitions uImage and minirootfs (see dmesg or /proc/mtd) We will not alter the original MTD/NAND layout, thus no need to change uBoot environment parameters, since we have plenty of space for kernel and initrd. As long as we don't touch the 0x000000000000-0x0000001a0000 region in NAND/Flash, we can always use uBoot to load & flash new data and images. If unsure, check dmesg or cat /proc/mtd to make sure that the MTD partition layout is correctly detected. If the bootloader area is overwritten then the device is "bricked" and can only be restored with lower level JTAG of the Marvell SoC.

  9. Install kernel and build new initrd

    apt-get install linux-image-marvell
    mkinitramfs -u

  10. When done and you see that the kernel and initrd is written to NAND, exit out to install program again and reboot system. It should look like this:

update-initramfs: Generating /boot/initrd.img-4.9.0-1-marvell

Using DTB: kirkwood-netgear_readynas_duo_v2.dtb
Installing /usr/lib/linux-image-4.9.0-1-marvell/kirkwood-netgear_readynas_duo_v2.dtb into /boot/dtbs/4.9.0-1-marvell/kirkwood-netgear_readynas_duo_v2.dtb
Taking backup of kirkwood-netgear_readynas_duo_v2.dtb.
Installing new kirkwood-netgear_readynas_duo_v2.dtb.
Installing /usr/lib/linux-image-4.9.0-1-marvell/kirkwood-netgear_readynas_duo_v2.dtb into /boot/dtbs/4.9.0-1-marvell/kirkwood-netgear_readynas_duo_v2.dtb
Taking backup of kirkwood-netgear_readynas_duo_v2.dtb.
Installing new kirkwood-netgear_readynas_duo_v2.dtb.
flash-kernel: installing version 4.9.0-1-marvell
flash-kernel: appending /usr/lib/linux-image-4.9.0-1-marvell/kirkwood-netgear_readynas_duo_v2.dtb to kernel
Generating kernel u-boot image... done.
Erasing 128 Kibyte @ 7f631f5c00000064 -- 48 % complete 
Writing data to block 0 at offset 0x0
Writing data to block 15 at offset 0x1e0000
Generating initramfs u-boot image... done.
Erasing 128 Kibyte @ 7f5d0f5c00000064 -- 128 % complete 
Writing data to block 0 at offset 0x0
Writing data to block 43 at offset 0x560000

The system is fully capable to run BorgBackup and actually performs a decent ~60Mbps SSH traffic with some tweaks. To take advantage of the Marvell CESA cryptographic accelerator, use the following configuration in /etc/ssh/sshd_config

# Custom ciphers to use marvell_cesa
Ciphers             aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
MACs                hmac-sha1,hmac-md5

You also need to specify this in you client configuration (~/.ssh/config)

G762 fan driver have also done some great work to make the G762 fan driver chip. This is unfortunally missing from the standard Debian kernel image. I didn't feel like recompiling a custom kernel, so I've just extracted the the module from a kernel build a did.

You can find it here:

Put it under /lib/modules/4.9.0-1-marvell/kernel/drivers/hwmon/ and run depmod -a, then add it to /etc/modules

Further explanation

The stock MTD/NAND layout looks like this:

Creating 5 MTD partitions on "nand_mtd":
0x000000000000-0x000000180000 : "u-boot"
0x000000180000-0x0000001a0000 : "u-boot-env"
0x000000200000-0x000000800000 : "uImage"             ~6M
0x000000800000-0x000001800000 : "minirootfs"         ~16M
0x000001800000-0x000008000000 : "jffs2"              ~10M

The bootcmd parameter of uBoot says:

nand read.e 0x1200000 0x200000 0x600000
nand read.e 0x2000000 0x800000 0x1000000
bootm 0x1200000 0x2000000

You see the connection? :)


Cheap Chinese camera teardown


It does however, have som decent specifications

  • 1280x720p h.264 video over RTSP
  • 802.11bgn single chain wireless
  • Microphone & speaker
  • microSD/TF slot
  • Some ONVIF compatibility
  • Solenoid IR-cut filter for night/day-vision
  • Infrared LEDs for night


The SoC is quite a beast.

Then there is some OP-amps for speaker/microphone and voltage regulation.


This is were the total meltdown is, as usual. The camera is discovered and controlled by an obscure unknown UDP protocol of some kind. It has to register to a Chinese cloud service called Cloudlinks then you have to use a very dodgy Android/iOS application called Yoosee to manage the registered devices. The Yoosee app is also used to configure the WiFi via a quite innovative "transmit by sound" technique.

The authentication also doesn't make sense and is probably very insecure.

Fortunately, it's accessible via RTSP with the URL rtsp://camera-ip:554/onvif1. And it will work fine without Internet-access. It also has a ONVIF SOAP interface on TCP port 5000, but it's quite unusable.

Reverse engineering

The real software author of the camera seems to be GWellTimes and the software product seems to be is named NPC, and the actual product might be this one.

The camera tries to contact the following servers on UDP/51700 or UDP/51880, then it uses more random UDP ports. It actually looks like some kind of tunnel. After I configured mine, I firewalled it for internet-access.       (Aliyun Computing Co., LTD)      (GorillaServers, Inc. (GORIL-3))        (Jeff King,      (Shenzhen Runxun Data Communication Co. Ltd.)       (Vcloud, Beijing Internet Harbor Technology Co.,Ltd)     (China Mobile Communications Corporation?)

It also tried to check for updated on some servers

If it gets a response that there is a higher software available, it fetches it

The file it downloads seems to be some kind of firmware at first, consisting of a JFFS2 filesystem and a binary ending

$ binwalk npcupg_22.00.00.14.bin
32            0x20            JFFS2 filesystem, little endian
3054100       0x2E9A14        ELF, 32-bit LSB executable, ARM, version 1 (SYSV)

If we unpack the JFFS2 filesystem, we can see that it's only a form av upgrade package, since it lacks kernel and a ordinary linux root filesystem. Probably it's only targeted to a flash partition for OEM customization. It seems to support various camera sensors. The config/*.xml contains video encoding settings.

Main application seems to be npc (4M), and gwellipc (997K) for more basic functions.

└── fs_1
    ├── config
    │   ├── image_ar0130.xml
    │   ├── image_h42.xml
    │   ├── image_sc1135.xml
    │   ├── image_sc2135.xml
    │   ├── video_ar0130.xml
    │   ├── video_h42.xml
    │   ├── video_sc1135_bak.xml
    │   ├── video_sc1135.xml
    │   └── video_sc2135.xml
    ├── config-鱼眼-20161124.rar
    ├── dhcp.script
    ├── gwellipc
    ├── language
    │   ├── cf
    │   │   └── PushMesg.txt
    │   ├── ch
    │   │   └── PushMesg.txt
    │   └── en
    │       └── PushMesg.txt
    ├── minihttpd.conf
    ├── npc
    ├── patch
    │   ├── ar0130.ko
    │   ├── dsa.ko
    │   ├── gpioi2c1.ko
    │   ├── gpioi2c.ko
    │   ├── hi_gpio.ko
    │   ├── jxh42.ko
    │   ├── motor_drv.ko
    │   ├── sc1035.ko
    │   ├── sc1135.ko
    │   ├── sc1145.ko
    │   └── sc2135.ko
    ├── readme.txt
    ├── sensors
    │   ├── ar0130.bin
    │   ├── jxh42.bin
    │   ├── sc1035.bin
    │   ├── sc1135.bin
    │   ├── sc1145.bin
    │   └── sc2135.bin
    ├── sound
    │   ├── alarm_1.amr
    │   ├── alarm_2.amr
    │   ├── alarm_3.amr
    │   ├── alarm_4.amr
    │   ├── alarm_5.amr
    │   ├── alarm_6.amr
    │   ├── alarm.amr
    │   ├── beingcalled.amr
    │   ├── calling.amr
    │   ├── ch
    │   │   ├── wifi_ap_mode.amr
    │   │   └── wifi_sta_mode.amr
    │   ├── clear.amr
    │   ├── di.amr
    │   ├── DoorBell.amr
    │   ├── en
    │   │   ├── wifi_ap_mode1.amr
    │   │   ├── wifi_ap_mode.amr
    │   │   ├── wifi_sta_mode1.amr
    │   │   └── wifi_sta_mode.amr
    │   ├── key_press.amr
    │   ├── numbers_ch
    │   │   ├── 0.amr
    │   │   ├── 1.amr
    │   │   ├── 2.amr
    │   │   ├── 3.amr
    │   │   ├── 4.amr
    │   │   ├── 5.amr
    │   │   ├── 6.amr
    │   │   ├── 7.amr
    │   │   ├── 8.amr
    │   │   └── 9.amr
    │   ├── Reset_ch.amr
    │   ├── Reset_en.amr
    │   ├── set.amr
    │   ├── set_fail.amr
    │   ├── set_ok.amr
    │   ├── Unlock.amr
    │   ├── WifiLink_ch
    │   │   ├── LinkFail_again_ch.amr
    │   │   ├── Linking_ch.amr
    │   │   ├── LinkOk_ch.amr
    │   │   └── WaitLink_ch.amr
    │   └── WifiLink_en
    │       ├── LinkFail_again_en.amr
    │       ├── Linking_en.amr
    │       ├── LinkOk_en.amr
    │       └── WaitLink_en.amr
    ├── upgfile_ok
    └── version.txt

14 directories, 81 files

The strings of the binary data at 0x2E9A14 also reveals some interesting lines.

$ strings endbinarydata.bin 
reboot -f

Probably a upgrade program in some way, that writes the JFFS2 to to mtd5 partition maybe?


  • Initial configuration needs to be done via Yoosee app, and needs online cloud registration to activate.
  • No simple web interface, only configurable by app or Windows "CMS" software
  • Video only, no JPEG stills
  • Video bitrate/quality is not possible to configure, usually about ~1-2Mbps.
  • Doesn't care about NTP options via DHCP - seems to sync tome via UDP cloud tunnel.
  • No complete firmware files available anywhere

I will in time try to get root access to the device, and see if i can change the video encoding bitrate and if it's possible to output (M)JPEG via the built in web server.

MQTT in Splunk

The sensor network consist of various Arduino-based nodes. Both AVR and ESP8622-based, using 433Mhz modules or WiFi in the later case.

I also have made a mobile micro-dashboard (not Splunk related) public for accessing when I'm not at home. It's a simple JQuery-made thing that fetches a JSON file held in memory, that contains the latest values sent via the MQTT network. If a value is older than 1 hour a red warning triangle will show to indicate that the value might not be updated.

Sorry for the Swedish. It says Kitchen, Fridge, Freezer, Balcony and Basement.

How are you doing these days? (English)

For a long time I just ran a Linux machine with a simple iptables-firewall. But when the need for wireless arrived, the choice fell on the Linksys WRT54G, which also took over the firewall duties. It was later replaced with a Netgear WNR3500L since it had Gigabit-ports.

Unfortunately, in a couple of years, most people have acquired wireless at home and the 2.4GHz domain was becoming very noisy with all neighbors. Then the ISP's started to ship their combined modem and WiFi-router to just everyone.

I realized that it was time to enter the 5GHz band, since my laptop already had support for this. I've also realized that I wanted to run OpenWRT, and the chipsets from Broadcom did not play well with the opensource community. So the choice fell on a TP-Link WDR3600. This dual-band router really does its job well and is basically made for running OpenWRT.

Why not DD-WRT?

DD-WRT felt phenomenal when it was released. All of a sudden you had SoHo-enterprise features that you never thought possible with cheap sub-$100 routers. But after a few years, I found the project a bit weird. There was never any stable releases, only new "builds" that seem to be the complete mess which builds that were stable or not. No changelogs, no security updates. The whole project seems to be a one-man-show, but at the same time some kind of commercial product? No one really knows. Are they still working on v24?

Why not OpenWRT?

OpenWRT is a great project. It is much more than just an alternative firmware; it is a complete solution for embedded platforms. But it is still "only" a Linux distribution to be fair, even if LuCI is a very nice interface. It also lacks some proprietary optimizations and features that only a manufacturer can have full knowledge of (due to NDA agreements, and so on...) There is also no continuous updates and security fixes. You simply have to nicely wait for a new release or build from trunk.

Hello RouterOS

I work with IT-security and networking equipment. It ranges from stuff sitting in a closet somewhere to 4-unit gear in noisy datacenters. These usually have very specific functions or exceptional performance, and exceptionally high price tags. What can you use at home, but without paying hundreds of dollars for hardware and licenses?

I can recommend the Latvian manufacturer Mikrotik with it's RouterOS and Routerboard. They made previously only a little more pricey pure router modules, but has now begun to use the same type of Atheros/Qualcomm chipsets such as TP-Link and others.


  • Has support for everything you would expect from entry/mid-level enterprise router.
  • They have different types of hardware depending on performance requirements ($40 to $2000).
  • They develop on their own hardware for their software and everything is tested, hence very reliable.
  • They have the opportunity to use the specific hardware support (NAT, crypto and forwarding in hardware)
  • They release new software continuously, and it is almost ridiculously easy to upgrade.
  • They have a proper CLI which is actually really good and useful (and colorful). Some big-player vendors should actually be ashamed when compared.
  • It is good quality radio design, construction and components.
  • Web interface is great to!
  • Larger models support encryption in hardware, providing lovely VPN performance.


  • Licensed - But new hardware includes one standard license, and it's not that pricey.
  • Their switches do not support IGMP snooping (Not quite sure this)
  • No "cluster" support - However, failover with standard VRRP is available.
  • Some of the cheap models (home-ones) have limited flash-storage - Not possible to use all functions/packages.

I myself have now this gear for the moment, on different physical locations.

  • RB260GS - Switch _ (SWOS, not RouterOS) _
  • RB wAP AC 802.11ac + 802.11n - AP
  • RB922UAGS-5HPacD - 802.11ac - AP + Firewall
  • RB hAP - 2.4Ghz 802.11n (2x2) - At my parents place

RouterOS Neighbours Neighbors list

Wireless performance Wireless performance is great to (2x2 11ac-40Mhz)

AirPlay on OpenWRT

If you have a OpenWRT-capable router with USB and a USB Soundcard laying around, you can now use it as a AirTunes compatible reciever.

I have built packages for bcrm47xx and ar71xx type SoC's for OpenWRT Barrier Breaker

Atheros AR71xx (for example TP-Link WDR 3xxx/4xxx)

Broadcom 47xx (for example Netgear WNR3500L)

Thanks to sm3rt for OpenWRT packaging:

If you are running Linux on your clients, you can always use PulseAudio for network audio streaming.


Shairport and Shairport-sync is now included in OpenWRT 15.05. Just install the packages :)