Previously I wrote about Tenvis cameras on Zoneminder, but now something new, but surprisingly similar in many ways. I've been playing with cheap DB Power 720p IP cameras. These appear to be re-badged MayGion cameras though I suspect there are many similar variants out there.

The one I got has some useful enhancements other than the obvious (resolution):

• IR-Cut filter that automatically (or manually) cuts in/out and better sensor makes the night footage much better, while also providing clean daytime colour footage
• SD card for recording.... or maybe other tricks (see below)
• Easily hackable allowing access to the OS and customization

This article goes through a load of extra things that you can do with this camera which may not be available in every version of the firmware, or worse may brick you camera. This article assumes a in-depth understanding of Unix / Linux for all but the most basic configuration described here. If you are unsure or don't want to brick your camera then stop now.

Initial Setup

On power up these cameras configure themselves on 192.168.1.111/24 with a gateway of 192.168.1.1 on wired ethernet which makes it very easy to configure a laptop on that network to configure them.

The web interface on port 81 hence you end up with http://192.168.1.111:81/ after which the username and password are both "admin"

Wide open

As it turns out these cameras have telnet open... yeah, straight into an unauthenticated shell! But very minimal busybox once you get in (no editors of any type!) so to do anything interesting a bit more work is needed.

This has both advantages and disadvantages: it's great to start poking around with the camera, but at the same time it rather blows things open so far as security when you can get OS access without authenticating.

The OS appears to be a flavour of embedded Linux, possibly OpenWrt/DDWrt derived. The camera is actually presented as a USB Camera (video4linux)

Hardware seems to be:

• CPU: MP_104 / MIPS 24Kc V4.12
• WiFi: RT2860STA
• Ethernet
• SD card (via USB)

API

These days if you don't have an API then you aren't alive... well, if you code anyway. So far as I can tell this is a MayGion camera (or relative) and the API seems to work accordingly.

Quick access guide is:

• /audio.cgi provides audio only in small frames, but don't put into browsers as they get very confused
• videostream.cgi provides an MJPEG stream
• videostream.asf provides an MJPEG stream with alaw sound
• All the above can be authenticated with appending: ?username=xxxxx&password=xxxxx (URL encoded)

Making the OS more usable

As mentioned above the user environment is very minimal with a cut-down build of busybox. Fortunately you can get a far more capable busybox built from http://busybox.net/downloads/binaries/latest/

I found the busybox-mipsel download works and has plenty of extra functionality as well as an editor (vi). Due caution needs to be used when downloading and using unknown binaries.

Since the internal storage of the camera is pretty near full, the busybox binary will need to go on an SD card.

Backups

If you are going to mess with this camera more then a backup is probably a good idea. It's rather easy to mess this camera up and if something doesn't work then it just repeatedly reboots which makes it difficult to recover. The simple way I did this was with the more capable busybox added on SD:

/mnt/sd/busybox-mipsel tar cvf /mnt/sd/allfiles.tar --exclude mnt/sd/\* --exclude proc/\* --exclude sys/\* /

Quirks and cures

Pointing weird directions

When the camera boots it positions it's self to a preset "center" position, but that's not very useful if you have set it up to be in a specific position and it gets rebooted - your CCTV recording ends up being of something other than what you wanted.

Fortunately with the more capable busybox it's easy to edit (vi) the config to change the "Center" position:

Edit /tmp/eye/app/cs.ini and change the section and settings:

[board/motor]   
xCenter=240
yCenter=136

... then reboot - any UI changes will overwrite this file

This defines the position that the camera will point at boot.

Repeated rebooting

This camera has a few quirks and one is that if it is isolated from the internet it will sit and repeatedly reboot. It seems it's trying to reach servers on UDP port 10240. From what I can work out this is to do with the P2P feature and disabling this stops this behaviour if no internet connection. Obviously you will need to start off with an internet connection to be able to disable this.

NTP and DNS

Irrespective of the DNS servers that are configured the camera will lookup NTP servers from 8.8.8.8 (Google's public DNS) which just means that on an isolated network or when given NTP servers that are not public this will fail. This appears to be hard-coded in the firmware (D'oh!) so a work around will be needed.

A simple way of dealing with this if you are running Linux on your gateway is to configure a DNAT rule to send DNS to 8.8.8.8 to your local DNS, something like:

iptables --table nat --append PREROUTING --protocol udp --in-interface $INTERFACETOCAM \
        --source $DBPWRCAM --destination 8.8.8.8 \
        --destination-port domain --jump DNAT --to-destination $LOCALDNS:53

Recording to SD

The moment the camera has a SD card it records video the the card. Fine if that's what you want, but as I'm using Zoneminder I just want to use the SD for things like the more capable busybox (only ~200k free on internal storage) rather than video.

To prevent recording you have to unhighlight everything in "Schedule Record" to stop recording to SD.

Software update & fail

I decided to try a newer version of the firmware which turned out to be a bad idea. First off the actual OS doesn't seem to be updated. The application (binary) that controls the camera and the web files (html & images) are what gets updated.

If the application fails to work then the camera might sit and reboot endlessly as happened to me. In my case I found there was a small window of a couple seconds after boot to telnet in, and run ps. Once you have identified the PIDs for the "applauncher" and "cs" processes which seem consistent between boots, the next boot you can telnet in during the brief window and kill these two processes to stop the rebooting.

After that I could use pftp to put files back from the backup I took earlier, of course remembering to switch to bin mode to ensure files are not corrupted. Credentials for ftp are the standard ones used for the camera.

Lock-down

Having telnet open is not ideal for normal running. I wrote a quick and dirty Python script to kill telnetd on the camera:

#!/usr/bin/python
# kills telnetd on devices for safety (normally open)

import time
import telnetlib
import sys

if len ( sys.argv ) != 2:
        sys.exit ( 'Usage: %s <ip address>' % sys.argv[0] )

time.sleep (15)

telnet = telnetlib.Telnet ( sys.argv[1] )
got = telnet.read_until ( '#', 5 )
if got == '':
        telnet.close ()
        sys.exit ()
telnet.write ( "/mnt/sd/busybox-mipsel killall telnetd\n" )
telnet.close ()

This takes a single argument of the IP of the camera. You can hook this up with a small shell wrapper script to control which devices this is run on from dhcpd on commit events with something like this in your dhcpd.conf:

on commit {
    set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
    set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
    execute ( "/etc/local-dhcpd-commit-wrapper", "commit", ClientIP, ClientMac );
}

The /etc/local-dhcpd-commit-wrapper script will need to check the arguments and determine if it should run the script to kill telnetd. I also do other stuff in my script like turning on lights at night when my phone connects to to the WiFi as I arrive home.

With Zoneminder

Before we start it's worth configuring a veiw-only user for security. This can be done in the Camera UI by setting the user group to Guest:

Zoneminder configuration for this camera is very similar in configuration to what I did for the Tenvis Cameras previously except that everything other than credentials gets ignored with this camera.

We will use the individual JPEG snapshot URL for this:

http://IPofCam:81/snapshot.cgi?user=view&pwd=complexpassword

As usual for Zoneminder click "Add New Monitor" and fill in:

• Give it a name
• Select Remote as the Source Type
• Choose your function, if you want a motion detected recording then "Mocord"
• You most probably want the camera Enabled
• Set the Maximum FPS which is the rate that you will be recording at when idle (no motion detected)
• Set the Alarm Maximum FPS which is likely to be the same as the rate setting you chose for the URL - this is the rate that it will record at when something exciting is happening
• You can change the Image Blend as needed depending on your frame rates and application. For applications where there are brief events (eg. someone running past down a corridor) then you may want to shorten this to detect far more brief events

Then onto the Source Tab:

• Remote Protocol of HTTP
• Remote Mothod of Simple
• Remote Host Name - put in the Host part of the addres (eg. IP of the camera), with no port
• Remote Host Port is 81
• Then the rest of the URL in Remote Host Path, so using our example: /videostream.cgi?user=view&pwd=complexpassword
• Remote Image Colours is 24 bit colour
• Choose Width and Height matching the resolution chosen - so 1280 and 720 for our example

This should have the camera working in Zoneminder provided it's all happy with stuff like shared memory for buffers and any remaining generic configuration.