- Do a normal install, boot up the system and enable ssh access.
Create the file /storage/.config/systemd/storage-kodi.mount with the following contents:
[Unit] Description=Kodi NFS Storage Requires=network-online.service After=network-online.service Before=kodi.service [Mount] What=192.168.1.3:/export/openelec/kodi Where=/storage/kodi Options=udp,nolock Type=nfs [Install] WantedBy=multi-user.target
Enable the job
systemctl enable storage-kodi.mount
Stop the current running Kodi
systemctl stop kodi
Mount and move current data, then create symlink
mkdir /storage/kodi mount -t nfs 192.168.1.3:/export/openelec/kodi /storage/kodi cp -vr /storage/.kodi/* /storage/kodi/ rm -rf /storage/.kodi ln -sf /storage/kodi /storage/.kodi
systemctl start kodi
I could drill a new hole for the cable though.
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.
Setup a TFTP service on a host of your choice.
You need to establish a bootloader serial console just as in the HowTo mentioned earlier. Beware, It's 3.3V TTL level serial.
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.
wget http://ftp.se.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/netboot/vmlinuz-4.9.0-1-marvell wget http://ftp.se.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-netgear_readynas_duo_v2.dtb cat vmlinuz-4.9.0-1-marvell kirkwood-netgear_readynas_duo_v2.dtb >> vmlinuz-dtb
Convert the vmlinuz-dtb image to a uboot image with
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n "Debian RND2 kernel" -d vmlinuz-dtb /srv/tftp/uImage-rnd2
I then used the installer-initrd for the Sheevaplug ESATA witch is very smilar and should work fine for the install.
wget http://ftp.se.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug-esata/uInitrd mv uInitrd /srv/tftp/uInitrd
Bring up the bootloader console (just hit any key at startup) and do the following.
setenv autoload no dhcp set serverip 192.168.1.3 tftpboot 1200000 uImage-rnd2 tftpboot 2000000 uInitrd set bootargs console=ttyS0,115200 earlyprintk bootm 0x1200000 0x2000000
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
Use the following machine configuration in
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: yesThis 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
/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-0x0000001a0000region in NAND/Flash, we can always use uBoot to load & flash new data and images. If unsure, check
cat /proc/mtdto 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.
Install kernel and build new initrd
apt-get install linux-image-marvell mkinitramfs -u
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 ...8<... Writing data to block 15 at offset 0x1e0000 done. Generating initramfs u-boot image... done. Erasing 128 Kibyte @ 7f5d0f5c00000064 -- 128 % complete Writing data to block 0 at offset 0x0 ...8<... Writing data to block 43 at offset 0x560000 done.
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
email@example.com 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
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? :)
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.
GOKE Electronics GK7102 - Single chip camera SoC
ARM1176 @ 600MHZ
512MBit DDR2 on chip
H.264 BP / MP / HP, MJPEG / JPEG / G.711 / G.726 / ADPCM / MP3 encoding
4 encoding processing capacity - 720P @ 30fps + VGA @ 30fps + QCIF @ 30fps + 720P JPEG @ 1fps
USB 2.0, Ethernet, SPI, I2S, UART, I2C and AES, DES, 3DES security engines
Macronix MX25L12835F - 128Mbit (16MB) SPI Flash
Mediatek MT7601U - USB 2.0 single chip WiFi
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.
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.
184.108.40.206 (Aliyun Computing Co., LTD) 220.127.116.11 (GorillaServers, Inc. (GORIL-3)) 18.104.22.168 (Jeff King, firstname.lastname@example.org) 22.214.171.124 (Shenzhen Runxun Data Communication Co. Ltd.) 126.96.36.199 (Vcloud, Beijing Internet Harbor Technology Co.,Ltd) 188.8.131.52 (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 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 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 ├── boot.sh ├── 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 /mnt/disc1/flash_erase /patch/bin/flash_erase /mnt/disc1/flashcp /patch/bin/flashcp /dev/mtd5 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.
For the moment it consist of a Python script that via the RouterOS API connects and polls for device information. The RouterOS API (https://pypi.python.org/pypi/RouterOS-api) is made by Tomasz Wysocki and is a really great work.
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.
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.
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
Wireless performance is great to (2x2 11ac-40Mhz)
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: https://github.com/sm3rt/OpenWRT-ShairPort
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 :)