Allowing ssh access to ReadyNAS RN312

After creating a few new users on the RN312, using the web interface provided with the device, I noted that none of the users could ssh into the NAS.

Turns out the new users are created without a default shell, resulting in a successful ssh login, followed by a terminated connection. No good.

For example, a user named charlie would have something like the following entry in the /etc/passwd file. Note the final bold characters:

charlie:x:100:102:charlie@yourdomain.com:/home/charlie:/bin/false

Change this to

charlie:x:100:102:charlie@yourdomain.com:/home/charlie:/bin/bash

 

Charlie should now be able to ssh into the NAS. By the way, you HAVE set up ssh keys for your users, right… Way more secure than plan text passwords, and a lot more convenient…

 

 

 

TI LaunchPad Stellaris and Anaren CC2530 Zigbee BoosterPack kit

I recently got the chance to evaluate the Anaren AIR CC2530 BoosterPack Kit, which is a ZigBee eval platform for TI’s LaunchPad products, i.e MSP430 and Stellaris.
Kudos to the good folks at element14 for providing the kit as part of their RoadTest program.

The review is found at element14’s site, but also here for completeness. I will also post further developments using the kit here on the blog, as described in the review I have some ideas around a cat-detector… So many projects, so little time.

The review follows below.
Continue reading “TI LaunchPad Stellaris and Anaren CC2530 Zigbee BoosterPack kit”

Netgear RN312 firmware upgrade 6.0.6 to 6.0.8

Firmware 6.0.8 just became available for the x86 based Netgear NASes. Interestingly enough, it is called “firmware” version, but to me (and others familiar with electronics and embedded systems) a firmware is low-level software running directly on the CPU/MCU. Maybe there are such components in the Netgear firmware too, but most part seems to be just updates to the NAS’ Linux environment (or more specifically: to the Debian Wheezy packages).

Anyway, that’s mainly semantics. My worry was that the upgrade would overwrite the 3rd party software I had previously installed (htop, tmux and CrashPlan).

Turns out there was no need to worry. All three works flawlessly also after the “firmware” upgrade. Nice.

Onwards!

tmux on Netgear RN312 NAS

If you spend any time at all at the Linux command line, you need tmux. Period. It makes you orders of magnitude more effective, there’s just no excuse for not using it.

Given that the RN312 NAS is x86 based and using Debian Wheezy, there’s an already compiled package for it. Installing it is trivial. Just ssh into the NAS, then issue:

apt-get intall tmux

That’s it. Copy in your favorite ~/.tmux.conf file, and you are set.

 

htop on the Netgear RN312

Just a quick post on how easy it is to set up the invaluable htop package on the Netgear RN312.  For those not familiar with htop, it’s a super-powered process monitor, way way better than the old legacy top command. Nice stuff, must have.

Turns out the pre-built package for htop is borked though (apt-get install htop fails) . Bummer.  Time to pull out the command line magic..

ssh into the NAS, then set up a build environment and a couple of dependencies. Compile and install (set the debconf to dialog and medium level):

dpkg-reconfigure debconf

apt-get install build-essential

<wait for looooong time>

cd /root/dl

wget http://downloads.sourceforge.net/project/htop/htop/1.0.2/htop-1.0.2.tar.gz

tar -xvzf htop-1.0.2.tar.gz

./configure; make; make install

Fail:

checking for refresh in -lncursesw… no

configure: error: You may want to use –disable-unicode or install libncursesw.

Ok, so let’s fix that, we need dev libs:

apt-get install libncursesw5-dev

./configure; make; make install

Fail 2, we need another set of ncurses dev libs:

apt-get  install libncurses5-dev

./configure; make; make install

… and that does it. Enjoy htop on your x86 based Netgear ReadyNAS!

CrashPlan on Netgear ReadyNAS RN312 – hello!

Edit: Installing according to the instructions below works, but it does place CrashPlan’s log and cache files on the very size constrained root partition of the ReadyNas. Especially the cache files will quickly fill that partition of you have lots of files.
It is however easy to move those cache and log files to a better location, so once done with the instructions below, check out this post for details on how to move cache and log.

 

I’ve been using CrashPlan for a couple of years now, it’s a great service. In particular I like the peer-to-peer backup feature, where I can configure my parents’ (or friends) computer to back up to my small headless server during the night, making sure they don’t loose their pictures due to some unfortunate keyboard sequence.. The paid-for service is very reasonably priced too, giving me unlimited backup space for $4.79/month, given a 2-year signup period. Nice.

The downside is that you must keep your computer on at all times. Sure, that might be fine, but given that I try to reduce the carbon (and energy, in general) footprint around here, I’d rather put my computers in sleep or hibernation when not used. The one exception I am willing to make is a good NAS, and possibly also a jump host that will give me ssh access to my home network. Maybe the two combined in a single server – or the jump host in a very small and low power server. Anyway, after years of trying out different setups, mainly focused around a) my iMac with an external USB drive, and b) headless servers (I have all of the Bubba servers, http://www.excitostore.com/sv/frontpage, awesome servers, but even the B3 is today slightly underpowered. Tough challenge keeping up with all the new hardware architectures coming to market. So when the Atom powered dual core Netgear RN 312 was announced it seemed like a nice platform. The java powered CrashPlan application should not be a problem (others have successfully installed it on other x86 powered Netgear NAS:es), it supposedly also nicely handles lots of UPS:es, including (I hope!!) the slightly uncommon Bluewalker UPS that I use. Anyway, getting CrashPlan up and running on the ReadyNAS was top prio. Turned out that some changes were needed, compared to the walk-throughs for earlier ReadyNAS versions. First, the usual disclaimer: One or more of the suggestions in this blog post and related posts on this blog may very well void the warranty of your NAS devices. So. Enough. Given the risk of myself having to re-do this at a later date, or for the benefit of others having the desire for the same setup, here we go:

  1. www.shasam.net has been invaluably helpful, providing general ideas on how to approach CrashPlan on ReadyNAS:es. Still, as the instructions there doesn’t work for the RN312 series, I feel it might be useful with some additional comments.
  2. On the RN312 (using the standard web UI), create a share named “Crashplan”. It will be stored under /data/Crashplan Enable ssh root access (once again, using the standard UI).
  3. ssh into the NAS, using something like ssh root@192.168.1.x, adjust the IP address as needed. Use the pwd of the admin user, that you set when configuring the NAS.
  4. create a working directory, I use /root/dl (as in “download”):
    [code language=”css”]
    cd
    mkdir dl
    cd dl
    [/code]
  5. Install Java:
    [code language=”css”]
    apt-get install openjdk-6-jre-headless
    [/code]
  6. Get CrashPlan (adjust as needed to get latest version):
    [code language=”css”]
    wget http://download.crashplan.com/installs/linux/install/CrashPlan/CrashPlan_3.5.3_Linux.tgz tar -xvzf CrashPlan_3.5.3_Linux.tgz
    [/code]
  7. You need to install some packages to get things working:
    [code language=”css”]
    apt-get install dialog
    dpkg-reconfigure debconf
    [/code]
  8. Set the debconf level to “dialog” and “medium”. It turns out the pre-installed version of cpio doesn’t quite cut it.. Replace it:
    [code language=”css”]
    apt-get remove busybox-cpio
    apt-get install cpio
    [/code]
  9. With Java installed and some environment changes in place, time to install CrashPlan:
    [code language=”css”]
    cd /CrashPlan-install
    ./install.sh
    [/code]
  10. Just press enter to use the default settings, except for where to store the CrashPlan data. Full conversation follows (with EULA slightly shortened). Also, line breaks were lost in copy-paste process, so what’s shown on screen probably differs a bit from the below:
    [code language=”css”]
    Welcome to the CrashPlan Installer.
    Press enter to continue with installation.
    Validating environment… detected root permissions 49581 blocks
    You must review and agree to the EULA before installation. Press enter to read the EULA.

    <EULA>
    Do you accept and agree to be bound by the EULA? (yes/no) yes
    What directory do you wish to install CrashPlan to? [/usr/local/crashplan]
    What directory do you wish to link the CrashPlan executable to? [/usr/local/bin]
    What directory do you wish to store backups in? [/usr/local/var/crashplan] /data/Crashplan
    What directory contains your SYSV init scripts? [/etc/init.d]
    What directory contains your runlevel init links? [/etc/rc5.d]

    Your selections:
    CrashPlan will install to: /usr/local/crashplan
    And put links to binaries in: /usr/local/bin
    And store datas in: /data/Crashplan
    Your init.d dir is: /etc/init.d
    Your current runlevel directory is: /etc/rc5.d
    Is this correct? (y/n) [y]

    Unpacking /
    ./CrashPlan_3.5.3.cpi … 49581 blocks
    /usr/local/crashplan/bin/CrashPlanEngine: line 113: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8.UTF-8): No such file or directory
    Starting CrashPlan Engine …
    Using standard startup OK
    CrashPlan has been installed and the Service has been started automatically.

    Press Enter to complete installation.

    Important directories:
    Installation: /usr/local/crashplan
    Logs: /usr/local/crashplan/log
    Default archive location: /data/Crashplan

    Start Scripts:
    sudo /usr/local/crashplan/bin/CrashPlanEngine start|stop
    /usr/local/crashplan/bin/CrashPlanDesktop

    You can run the CrashPlan Desktop UI locally as your own user or connect a remote Desktop UI to this Service via port-forwarding and manage it remotely. Instructions for remote management are in the readme files placed in your installation directory: /usr/local/crashplan/doc
    To start the Desktop UI: /usr/local/bin/CrashPlanDesktop

    Installation is complete. Thank you for installing CrashPlan for Linux.

    root@RN312:~/dl/CrashPlan-install#
    [/code]

     

  11. Reset debconf to non-interactive (using “noninteractive” and “medium” as settings):
    [code language=”css”]
    dpkg-reconfigure debconf
    [/code]

With this, it should be a smooth ride following the previously mentioned blog post to set up CrashPlan. Worked for me, a few hours later the RN312 has now backed up a few GB and progressing nicely. The full backup will take weeks or more, but that’s fine – the summer is long and I have other backups in place meanwhile.

Superprobe meets vintage multimeter

One of the first tools I built myself many, many (decades!) years ago was a logic probe. At the time things like yellow LEDs were still a bit rare and cool, but this baby had both red, yellow and green LEDs to indicate TTL logic levels. It was a true rat’s nest of wires – and everything stuffed into one of those plastic cases for one-time travel toothbrush that you (used to) get at some hotels. A stiff copper wire was glued to one end of the case. Ugly as h-ll, but it worked quite nicely.

Years have passed, and I actually found that probe a year or so ago. It still worked, but with access to things like multi-channel logic analysers and digital storage oscilloscopes, that probe was sent to rest at the place where electronics never return from.

Still, the basic concept of a logic probe IS kind of nice. And as some people have taken this concept and extended it to include a bunch of other tools in the same circuit, I thought I’d spend some time building a new probe.

It’s really just a Superprobe in a somewhat unique (probably not, but I like the concept..) case. The Superprobe exists in various flavours, the ones I’ve liked best so far are the original onethe MKII one, and the one from Dangerous Prototypes.  The one I built is a mashup of the three, dropping the voltage reg (as I feed my probe from a USB cable, which provide a stable +5V that the PIC can use. Adding programming headers á la the DP probe was a must-have. But dropping the display resistors, seems to work just fine without them.

The project really kicked off when I was cleaning out some boxes of old stuff, and found the first digital multimeter I ever bought, probably around 1985 or so. It is a total piece of junk, was probably the same back then, but still expensive at the time. Interestingly enough, the main ADC chip of the DMM was a MAX131CPL – which is still available for purchase today!!

Off to work then.
After ripping apart the DMM and stripping away all components, LCD, daughter boards etc (all through-hole components, of course. This is pre-SMD times.) I was left with some space in the DMM that should nicely handle the Superprobe circuitry. It might even be possible to squeeze a Dangerous Prototypes Part Ninja in there, and then multiplex the display between the two tools… Nah, one thing at a time, I’d rather finish the probe first.

It all comes together quite nicely, with a mini USB jack providing power to the probe, the probe’s two push buttons are hot glued to the upper left/right sides of the case, making it easy to operate them both when the meter is on a table, and when it’s held in hand (in that caseit’s actually possible to operate the whole probe with a single hand, using thumb and index finger, while the probe rests in the palm. Nice!).
The input jacks from the original DMM are re-used and soldered to the input and Gnd of the probe, with one of the original mechanical range switches wired as on/off for the probe.

Works like a charm, the pictures below show the probe while in use.
Only one small glitch, not sure what’s going on. When the probe is turned off, it needs a minute or two before it agrees to turn on again. Some capacitor that need time to discharge, I guess. Thinking about adding a reset button.. should be an easy thing to add, just hooking pin 1 to ground through a small push button.

All in all – nice little project that is likely to be quite useful up ahead.

Reverse engineering Macbook Air FaceTime camera, part 1

A severely cracked 13″ Macbook Air display came my way some time back. The LCD panel was obviously damaged, but it would be interesting to see what makes such a great display tick, and maybe parts of it could still be used? I believe the display came from a Late 2010 Macbook Air (which would indicate an A1369 type construction), but can’t be sure. Anyway – ideas included

  • Keeping the back lighting (assuming it works) and camera, mounting the whole display on a flexible arm next to the work bench. Given the high intensity of the back lighting, it could then (maybe) provide ambient lighting AND video recording of whatever was being worked on. Maybe with a LED light and camera on a separate flexible arms.
  • If the LED backlighting drivers were toast, there should still be some nice white LEDs in there for scavenging.
  • Same thing for the camera, I believe it to be a 640×480 pixel device, nothing too exiting but could still be useful.

Turns out it’s not entirely easy to disassemble these displays. They are sealed together with very strong tape. Heating the bezel helps a lot, but it’s still a fair amount of work – and given the delicate components beneath the bezel, you might want to think twice before doing this on a laptop you care about.. Some good instructions found here, btw. Results so far:

2013-02-19_10-41-22_smallPrying the bezel open…

…before applying heat with a hot-air SMD rework station (regular heat gun would probably also work, if you are careful):
2013-02-19_10-44-38_small

Voila! Bezel is free:
2013-02-19_10-56-14_small

Now the tricky part. The cable from the cable is a thin wire with some kind of textile cover, for strengths I assume. It goes through the hinges and there is no way (as far as I can tell) to get the cable through there, without cutting off the (very small) connector that normally connects to the computers Left I/O (a.k.a. LIO) board. Cut.

Now the whole camera assembly can be removed. It also includes the ambient light sensor, which communicates over I2C. Unknown protocol for that one though – one for the future to investigate..

2013-02-23_22-55-38_small
Very tiny 6-pin connector, normally going to the LIO board.
2013-02-19_13-11-34_smallCamera module exposed in the top part of the screen. Held in place with 2 small screws.


2013-02-23_22-32-08_smallCamera board. 

2013-02-19_13-17-59_smallThese things are small – fingers included for scale reference.

With six wires in the cable it’s pretty clear that 4 are for USB (+5V, Gnd, Data+, Data-) and 2 for I2C. That cable is however crazy small – it’s about 2 mm diameter. Once the outer layer is off, you see 6 even thinner cables. 2 are black, 4 transparent. Which ones are which?

Google is your friend. Turns out there are schematics to be found if you Google long enough. Turns out you need schematics for the LIO board though, in order to get the pinout of the camera/ALS cable, and it’s nowhere to be found for the A1369. Did find a schematic for the A1370 model though (same computer but 11″ screen), with a bit of luck that cable is the same between models.

The 2 black ones are prime candidates for +5V and Gnd. Cutting away the insulation revealed that the cables are shielded, with a center wire that is barely visible to the eye. It took several attempts before I had separated the wires from the sheilding, and then done the same with the other 4 wires. Soldering these onto an old USB cable was then easy (but ugly!!):

2013-02-28_14-09-48_small

Still, it doesn’t work. The camera is not recognised on an iMac with latest OSX, nor on a Windows 8 laptop. Happened to have a Raspberry Pi lying on the work bench, tried it too with same result: nothing.

But wait… doing a “tail -f /var/log/messages” on the RPi showed that it DID recognise the camera, but that the camera wanted more power than a non-powered USB hub could provide! Placing the camera into the RPi’s regular USB port made it appear nicely when doing a “lsusb” command.

Still, it didn’t work when I connected the camera to the Windows or iMac machines – strange.

Also, the RPi loose contact with the camera after a while – no idea why. Could maybe be a bad USB cable (it’s from an old mouse using USB 1.1 – maybe that’s a problem??), or is there too much noise introduced by the ugly splicing of cables that I’ve done? No idea… More investigation needed. Anyway, the camera enumerates with USB id 05ac:850a, which indeed is an Apple FaceTime camera – nice!

Smoke tester from Dangerous Prototypes

A while back I got a free PCB from Dangerous Prototype’s Free PCB program. It’s a nice little board designed to provide easy current monitoring during prototype stages of a project. Features include over-current tripping with visual indication, as well as dual 5V and 3.3V supplies.

So, a week or two ago I was about to reverse engineer a laptop camera (built with very small components…). The camera’s attaching cable has unknown pinout, but system block diagram indicate it’s a USB 2.0 device. The cable is a 6-wire variant, so it shouldn’t be too hard figuring out which wire does what. It would however be nice to have a controlled power source feeding the camera during the work.

Enter the smoke tester… I figured I would build it, to the extent possible, with parts already found in the lab, if needed maybe even scavenging some old computer or similar..

The result is pretty nice:

smoke_tester_20130227

Some comments/feedback on the design:

  • Input power screw terminals don’t have +/- marked on the board.
  • Holes for bana jacks too small for any of the jacks I’ve tried.
  • Really nice with the three parallel pads for INA 138 load resistors. They give good flexibility for selecting shunt resistors for the INA 138. For example, I used a 0.1 ohm (instead of 0.075 ohm as suggested in the schematic) shunt resistor, which means the load resistor should be 50 kohm. Easy – two 100 kohm resistors in parallel does the trick.
  • Documentation is very limited, basically just a forum thread and schematics (that don’t include all component values, e.g. R13 and R14.

A few components are missing on thew board:

  • USB out connector. I had a hard time finding an SMD connector that would work. Figured I’d mainly be using the screw terminals anyway.
  • Banana jacks. Going through the parts bins here, all the banana jacks were too big to fit in the PCB’s holes. Those wholes could be a bit larger, IMHO.
  • Input power jack. Couldn’t find a suitable SMD one, but as I will be taking power from a wall wart with USB output I will be fine.
  • R13, R14. There is no value for these in the schematics (as far as I can tell), leaving them out thus. But as the USB out connector is unpopulated anyway, it’s not a problem (right now). Edit: They should be ca 20 ohms.

Links:
Dangerous Prototype’s forum page

iTerm2 + tmux + Fish = looks great!

If you spend any time at all at the command prompt in OSX or other Linux-ish systems, tmux is a must. Basically it gives you persistent shell sessions, once using it you’ll wonder how you ever got by without it… 

For OSX the easiest way to get tmux is via (the also excellent) Homebrew. After installing Homebrew, just do a 

brew install tmux

from a OSX prompt (you ARE using iTerm2, right? …Rather than OSX’s rather horrible built-in Terminal app…?)

Add to the mix the nice Bash replacement Fish, which gives you all sorts of command line goodness (color coding, auto-completion, …). Very nice!