https://www.sparkfun.com/products/11114
Fairly inexpensive little microcontroller if I do end up happening to need one for something; a little more work than the Uno’s which are a little more complete and priced commensurately.
Received the two bargain PogoPlug devices I had ordered from Adorama for $14.99 each the other day, and at unboxing it initially appears they may be the more desirable E02 models as opposed to the Oxnas P21 units they were indicated to be on the product page and that I recently linked instructions on a hack for. Last time I ordered one of the Pogo units something similar happened and I also received an E02 device which was fairly easy to load an alternate OS image on (though I didn’t do a great job with getting that project completed), but it seems to be pretty hard to tell what you actually have with the Pogo units until you actually boot them up and get a chance to look aft the environment (short of physically opening the chassis).
I first configured the MAC addresses on my Pogo units in the DHCP configuration on my Asus router with Tomato firmware so I’d have a good reference as to where and what they were going forward (there’s a good chance they will come and go on my network over time, and it’s always nice to be able to look at my lease table and know what’s what). I’ve been meaning to take some power draw measurements on these units for awhile now, as I have some curiosity as to whether I might be able to power them from a solar cell or cells. To test this, I connected the ethernet cable to the first of my Pogo units and then plugged it into my Kill-A-Watt device. Utilization seems to be fairly steady around 5.0-5.3 watts just sitting idly after booting with only the ethernet cable connected. Adding a USB flash drive brings the draw up to 5.4-5.8 watts. Finally, the Encore ENUWI-G2 wireless USB dongle I have brings it up to 6.0-6.1 watts (before loading an OS that will support it, so this value may change). I will leave the Kill-A-Watt connected as I continue and try to document some readings after connecting a USB drive, wireless USB device, and putting the unit under some load. My next step was to access the device via SSH. As noted in my earlier post, there are some instructions for this at http://archlinuxarm.org/platforms/armv5/pogoplug-v2-pinkgray. I had to enable SSH access via the my.pogoplug.com site as I was not able to log in directly, but that was fairly straightforward to do.
After getting SSH enabled and SSH’ing to the device, my intent was to load Debian Wheezy, as I’m a bit more familiar with the Debian package management and structure. Please be advised that the notes below are not yet complete, as I am currently working through them. Update uBoot on your DockStar, GoFlex, or PogoPlug NAS – I did this, answered “yes” to the prompt to disable pogoplug services. The installer recognized the device as a 2097 (Shevaplug), but this appears to be correct at least until a kernel that is patched for the E02’s is applied. Just as Jeff’s instructions at the above page show, here’s what I ran:
cd /tmp wget
http://projects.doozan.com/uboot/install_uboot_mtd0.sh
chmod +x install_uboot_mtd0.sh ./install_uboot_mtd0.sh
I then ran /usr/sbin/fw_printenv and recorded the output from the command for later reference in case I encounter a need for it. My next steps were to prepare the drive to receive bodhi’s kernel/rootfs package noted below. To do so, I issued the commands from steps 4 through 7 of the instructions at archlinuxarm.com, as follows:
/usr/sbin/fw_setenv usb_rootfstype ext3
/sbin/fdisk /dev/sda
#responded to prompts with o, p, n, p, 1, accept defaults, w
wget http://archlinuxarm.org/os/pogoplug/mke2fs
chmod +x
mke2fs ./mke2fs -j /dev/sda1
mkdir usb
mount /dev/sda1 usb
I wanted to get netconsole working before going any further. First I initiated a netcat listener on port 6666 on another box with MAC 00:16:6F:56:96:9E and IP .194 with nc -l -p 6666. I then attempted to load the configfs and netconsole modules as indicated in the instructions, but was not able to locate modules.dep – so I assume will have to proceed with getting the updated kernel and rootfs loaded first. Linux kernel 3.9.11 Kirkwood package and rootfs, last updated July 26 2013 (as of the time of writing) The bz2 package was hosted on Dropbox and I had downloaded it to my PC, but thought it might work better to just grab direct. I discovered that the native wget in the Pogo firmware wouldn’t handle the HTTPS it redirected to, so a bit of a dirty hack with a reference from here (one of the later ones that uses echo to apply the HTTP 200 OK header was required since I couldn’t stuff this information into the binary) allowed me to grab it using netcat since I didn’t have a webserver handy on the box I had downloaded it to. I started the following on the box that held the Debian rootfs: while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; cat Debian-3.9.11-kirkwood-tld-1-rootfs-bodhi.tar.bz2; } | nc -l -p 8080; done Then, from the Pogo SSH session, I executed wget http://download.host.ip.addr:8080/Debian-3.9.11-kirkwood-tld-1-rootfs-bodhi.tar.bz2 (from the root directory of the newly formatted flash drive). This ran through and downloaded the file properly, and once it completed it reported “stalled”, so I issued a Ctrl+D on the server end and the connection terminated properly, with the file appearing to match according to an MD5 checksum. I then untar’ed the file on the Pogo with a tar -xjf Debian-3.9.11-kirkwood-tld-1-rootfs-bodhi.tar.bz2. This took a couple of minutes to complete, and unfortunately I didn’t think to check my power draw until it completed and was back down to ~6.3 watts. Once complete I edited the fstab file and set the /dev/root type to ext3. Finally, I issued a sync and /sbin/reboot and waited for the device to come back online. I could tell when it did, as the front LED came up orange (due to the hardware reference to the Sheva, mentioned previously). Unfortunately I wasn’t able to ping or SSH to it, so I gave it a hard power cycle and also cleared its DHCP lease from my router. Pings replied when it came back up following the hard boot, and I also noticed that the front LED had come up green, which made me wonder if the hardware ID had been updated automatically. After removing the cached fingerprint from my SSH known hosts file, I was able to SSH to the Pogo and log in with username root and the default password of root, which I changed. I then configured my regular user account as I normally do. Upon checking fw_printenv, I see that the arcNumber is still showing as the Sheva 2097, as does a cat /proc/cpuinfo. I ran across this thread which advised to issue a fw_setenv machid dd6, which I did followed by a sync and a reboot. When things came back up, cat /proc/cpuinfo now shows the device as a Pogo E02.
/usr/sbin/fw_printenv output
ethact=egiga0 bootdelay=3 baudrate=115200 mainlineLinux=yes console=ttyS0,115200 led_init=green blinking led_exit=green off led_error=orange blinking mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data) mtdids=nand0=orion_nand partition=nand0,2 stdin=serial stdout=serial stderr=serial rescue_installed=0 rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi force_rescue=0 force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi ubifs_mtd=3 ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done usb_scan_list=1 2 3 4 usb_scan_1=usb=0:1 dev=sda1 usb_scan_2=usb=1:1 dev=sdb1 usb_scan_3=usb=2:1 dev=sdc1 usb_scan_4=usb=3:1 dev=sdd1 usb_init=run usb_scan usb_device=0:1 usb_root=/dev/sda1 usb_rootfstype=ext2 usb_rootdelay=10 usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset ethaddr=00:25:31:04:XX:XX arcNumber=2097
http://www.howtoforge.com/installing-debian-squeeze-on-pogoplug-v3-oxnas-cleanly
I bought a couple of these on a discount deal today. My previous model ended up being an E02 and less of a struggle, but ran across this site for dealing with the Oxnas and thought I’d better bookmark it now. I’m thinking of using these devices either as a headless barcode scanner for grocery and inventory purposes, or possibly some tinkering for door/window sensors or an Internet relay for my garage door.
http://tldp.org/LDP/abs/html/here-docs.html
I’ve often struggled with how to best document the setup on a*nix box to make it is replicable as possible, and it finally came to me today while reading a document I linked in a previous post that I could just do it as a shell script that would create the configuration for me, using comments to document anything that needed to be called out. The “here document” reference linked above provided some helpful instruction on how to best write out some of the text configuration files.
http://inai.de/documents/Perfect_Ruleset.pdf
Glad I ran across this if for no more than the trace functionality. You don’t know what you don’t know.
iptables -t raw -A PREROUTING/OUTPUT [...] -j TRACE
The whole document is worthwhile and contains some fantastic advice if you’re getting into more advanced iptables rulesets.
I’ve been thinking about, and even making attempts at, getting Gallery set up within my home network to allow automatic uploading from my Android devices. There are a few things I wanted to do as part of this post, and since I’m getting around to doing it at 11:00 at night, it’s going to be more of a notes-style document than a well-structured post.
First, my goal. I want to be able to automatically upload images taken on my Android devices to a “private cloud”… also known as a computer (VirtualBox VM, actually) on my network running the Gallery software. I want this to be at least as simple as it currently is (I currently use Dropbox with instant upload enabled on both my wife’s and my phones). I want our uploads and the account information associated with them to be secure, both on my private network and particularly across the Internet if I decide to go that route. I have been thinking about setting up a trusted certificate authority for some time. It’s an opportunity to learn and practice with software I don’t use on a daily basis. I have an innate distrust for the cloud. And because I think I can and I want to confirm.
Why am I doing this? Dropbox works fairly well, and it’s nice to have the pictures replicated to both the cloud and our PCs… but we have exhausted our space (if you don’t already have Dropbox and would like to sign up via the link above, that will get me another 500MB 🙂 ). While there are a couple of workarounds for this such as moving all the current photos out of my upload folder, there are some things I gain from Gallery that I’ve been wanting. I may make an effort at integrating the Dropbox functionality alongside Gallery at some point down the road, but there are several steps to get there first. My wife also typically turns off automatic upload and replicates images manually. I think she told me why, but I’ve forgotten; I’d like to get this set back to an automatic function so it’s not something she needs to remember to do.
Here’s a list of the parts involved in my venture, and a short explanation of why:
This ends up being a moderately complex setup for a “typical” home environment. Some might even say it’s excessive. However, when assembled together, each of these pieces helps to reach the aforementioned goal.
I actually started down this path a little while ago and had a few of the foundational constructs in place. VirtualBox was installed on my XP host system. I had downloaded and configured a VM using the TurnKey appliance turnkey-gallery-12.1-squeeze-i386-vmdk and performed the basic setup for the TurnKey appliance. I had installed the ReGalAndroid app on my SGSII and attempted setup with SSL, and discovered that a self-signed certificate on Android just wasn’t good enough. Attempting to connect to the Gallery over my wifi connection via SSL yielded a “No peer certificate” error. Not particularly surprising considering the SSL cert on the Gallery server was self signed.
So, at this point I essentially have two problems to address that more or less boil down to a single problem: I need to create my own personal trusted CA (which has been near the end of my todo list for quite a while), use that CA to sign a certificate for the Gallery server (and preferably other internal web service servers), and trust certificates signed by my new private CA on our Android devices and internal computers. I’ve made some effort at this previously as well. I’m currently running PCLinuxOS on the laptop I typically use, and ended up annoyed about/failing to complete creation of a CA on that platform (especially in combination with my desire to store the CA in a TrueCrypt volume).
This evening I set out to create the OpenSSL CA on a well-established Ubuntu box on my network, largely based on the instructions at https://help.ubuntu.com/community/OpenSSL. This didn’t get completed, largely due to documentation efforts and to searching for a window I thought I had open regarding trusting new CA’s on Android. At this point, I need to spend some quality time with iptables on another project so I’ll try to pick back up from here later. (This highlights another minor gripe/difficulty/annoyance I’ve had… serial posts in WordPress… there has to be a good way to do it, and some day I’ll probably need to take the time to do so.) Once I finish creating the CA, my next steps will probably involve either creating a TrustManager on Android as documented here or importing a new (private) CA root certificate as documented here.
After creating the necessary certificates largely as indicated in the Ubuntu OpenSSL link, I copied the certificate and private key for the Apache server for my gallery page over to the Gallery appliance. I then ran a2enmod ssl as root to enable mod_ssl on the Gallery server per instructions at https://help.ubuntu.com/10.04/serverguide/httpd.html, HTTPS Configuration section, and received a report back that mod_ssl was already enabled. I then moved the certificate and private key to /etc/ssl/certs and /etc/ssl/private, respectively, ran a2ensite default-ssl, and modified the SSLCertificateFile and SSLCertificateKeyFile directives to point to the correct certificate and key. Though I am still expecting to need to create a concatenated certificate chain with the CA certificate and the server certificate, I went ahead and tested a restart of the server to see what I got.
I received a certificate error/”problem with the certificate on this server” page in IE, much as I had expected – the client I was connecting from doesn’t even trust my new CA as a root yet. I continued past the error, and noted that I will probably have to do a little work on the default-ssl site file in /etc/apache2/sites-available, as it doesn’t load directly to the gallery page; much of that should be able to be copied from the ‘default’ site file in the same directory, and I will play with that later. I first wanted to see if I could get rid of the SSL error on the default Apache page, so I installed my new root CA public certificate as a trusted root CA on that box and retried loading the page. SSL loaded cleanly, oorah!
So, to enable Gallery on HTTPS, I checked /etc/apache2/sites-available/default. No reference there. Turns out I needed to edit /etc/apache2/sites-enabled/gallery (they didn’t do a symlink as is done for the default sites). I updated the VirtualHost section for *:443 to include the cert and key directives from the default-ssl config file, ran a2dissite default-ssl to disable the default-ssl site, and restarted Apache again. I was then able to load the gallery site with HTTPS and no errors from that system.
I copied the public certificate for my root CA to my Dropbox, clicked on the .crt file in the Android dropbox app, and was able to install the certificate after setting an unlock mechanism. Following that, I tested access from the ReGal Android app, but received a mismatch on the CN. Apparently the ReGal app will not accept a match on an altName, and I will need to match the FQDN (which I will have to use for the connection so it will work both when I’m at home and when I’m on the public Internet). Time to re-issue the certificate with the CN set to the FQDN and the hostname as a subject alt name.
After correcting and replacing the certificate and key, and revoking the old one for whatever that was worth, I encountered a new error with details “net.dahanne.gallery3.client.business.exceptions.G3ItemNotFoundException”. This was fixed by enabling the REST module as indicated here. Once that was done, I was able to establish a secure connection to the gallery!
It’s been nearly a year now since I parked my 1989 Toyota Camry because the power steering pump was leaking profusely, to the point where I was uncomfortable with the mess it made whenever I parked it. I finally got tired of throwing away a hundred dollars a month driving my Suburban and found the time and motivation to shove it into the garage a few weeks ago and have been working on diagnosis and repairs in my spare time since then. This post is a combination of documentation and reference for myself, and a collection of information that may perhaps prove helpful to someone else (or serve as a reminder for me) on future repairs down the road.
I’ve been told that one of the more common failure models with the power steering on these models of Camry is for the high pressure hose to deteriorate to the point of failure, essentially becoming porous. I had performed some investigation last year prior to parking the vehicle, and as best I could tell given the limited visibility position of the pump and hoses and the volume of fluid leakage, the problem didn’t appear to be a hose failure, but within the pump itself.
I’m fortunate to have a Toyota expert in the family who does a lot of work on these cars who provided me with some helpful suggestions and parts. The initial challenge was to get everything cleared out so I could get to the pump for removal, which was no small feat itself. Autozone has a pretty good document on removal and installation of the power steering pump, which I referenced several times. I did have difficulty accessing the top 14mm bolt and ended up supporting the engine with a bottle jack and wood block under the oil pan and removing the motor mount on the passenger side so I could gain access with a socket and universal/wobble joint. As well, I had some difficulty with the pressure hose attachment on the pump which I had pre-fastened to the replacement pump prior to installation, but which I found to be loose after I got things in place. I addressed this with a socket, universal joint, and extension coming down through from the rear of the engine, but have not yet had a chance to see how it has held up.
Before putting everything back together in its final configuration, I wanted to do a test run and make sure I had cured the leak. At that point I discovered I had further problems with lack of fuel to the cylinders and/or lack of spark. I pulled a spark wire off and held it near ground while attempting to crank the engine and didn’t hear a spark. Further testing included:
Diagnostic module jumper pin locations.
At this point, I received the suggestion, advice, and parts to replace the distributor assembly. Unfortunately my no spark condition appears to have persisted following replacement of the distributor. I was somewhat surprised, as the original had an apparently characteristic oil-soaked coil, and I could see where oil had been dripping down out of the distributor onto some of the heater hoses and other coolant-carrying hoses below it.
My next steps are to start performing some voltage tests and see what I can come up with at different points in the system. I fear I may have sustained some damage to the ECU in my previous attempts to jump start the car with the old, very dead battery.
Update 7/28:
I went out to work on the car yesterday afternoon and hooked up the air intake sensor just for the hell of it and gave it one more crank, and got a couple if definite spark/fires. After some waiting and additional cranking and a few sputtering seconds of runtime, I got it started up with a long burst of white smoke. Why I couldn’t get it started before, unless of course the airflow sensors were holding it down, I can’t say for sure. but it’s now reassembled and I’m looking forward to having it back as my daily driver.
