Public Key Authentication - Update

Turns out it's not easy to uninstall Ubuntu's encrypted home directory feature either, at least not while logged in over an ssh session. All I succeeded in doing when attempting to uninstall was screwing up both computers so bad I can't log in to them any more, and losing all my files. (Luckily there wasn't much on there yet to lose.)

As long as I have to go to trouble of digging these computers out and hooking up a keyboard and monitor so I can reinstall everything, I'm going to put Debian on them instead.

Public Key Authentication

I haven't been updating this blog lately because I've been trying to get my webserver set up first, so that I could put the pictures there and just link to them from the blog posts. (Uploading pictures to this blog is a tedious process, so I'm planning to create a website that I can just drop a folder full of pictures onto and have them all display nicely. I suppose I could just get a Flicker account instead, but I like doing things the hard way.)

So that I won't have to type my password over and over again to manage my webserver, I took an evening to set up public/private key authentication so I can just use that to prove to my webserver who I am when I log in, and then I don't need a password. Well that was the plan. It ended up taking an evening, then a weekend, then another few evenings, then a week... Every time I thought I had everything set up properly, the next time I came back and tried to log in, the key didn't work. Eventually it got to the point where I'd make a key, it would work exactly one time, and then never work again until I made a new key. (If you know how public/private keys work, this makes NO SENSE. But there it was.)

I spent more time troubleshooting this problem than all the cumulative time I will save from not having to type a password in the future. Nothing wastes your time like a technology designed to save you time, right? But I'm stubborn and the longer this went on the more determined I got to figure it out. See, I have a theory about life: success or failure is self-reinforcing between your beliefs and your actions. If you believe you can't make technology work for you, then when faced with a problem you'll give up too soon. By failing you proved right your own conviction that you would fail. Because you'll never know if the right solution was miles away from what you attempted, or whether it would have been just around the corner. On the other hand if you maintain an unshakeable belief that eventually, something you try will work, eventually it does, and you vindicate the confidence you had in the first place.

Turned out the problem in this case stemmed from an innocent decision I made when installing Ubuntu Linux on the server. In this new version of Ubuntu, they added a feature for encrypting your home directory. The install program asked me if I want to do this, and explained that it would be perfectly transparent to me; the operating system would magically decrypt and mount the home directory for me when I log in, and safely unmount it when I log off. Totally convenient - I'd never notice anything different. "Why not?" I thought. It didn't sound like much trouble and who wouldn't want more security on their webserver? So I left it enabled. BIG MISTAKE.

I would never have guessed there would be an interaction between this feature and using public/private key logins until I was looking at the ssh logs to try to figure out why I couldn't log in with my key. At first I thought I had the wrong log - why were there messages from the home directory encryption service mixed in with my ssh logs? And why was it not finding the key sometimes? Wait wait the order of those operations doesn't look right - shouldn't it be decrypting the home directory before looking in it for the key? Ahhhhh... Dammit. Now I get it.

Here's what was going on: the way public/private key ssh logins work is the server looks in your home directory for your public key to use to recognize you. But your home directory is encrypted. It gets decrypted for you when you log in. But you can't log in until it uses the public key to authenticate you, which it can't pull out of the home directory because it's still encrypted. "There's a hole in my bucket, dear Liza, dear Liza..."

You can verify if you've got the same problem as I did: as long as you're logged into the server in one terminal window, public/private key authentication will work in a 2nd terminal window. Log out of all the sessions, and now you can't authenticate anymore with your key. Log back in, and now your key works again in other terminals too. If this works, send an angry email to Canonical. Tell them I sent you.

The moral of the story is don't use the encrypted home directory feature, it was released half-baked. Have you heard the expression "Beware Greeks bearing gifts?" The meta-moral here is beware operating systems bearing gifts of "features" you didn't need!

Final Days Before Robot Competition

The Hardware is (mostly) done but as usual Software is holding up the show. Lateness is the nature of software; it's worse with robots because given the choice between finishing the hardware and finishing the software, you work on the hardware first: the software can't get around without a body. Then you try to get all the software done in the final 10% of the schedule. I told my team (only half joking) that the first time it runs the whole course, if it runs it, will be at the starting line at the competition!

Testing the GPS is particularly challenging because you have to be outside in a big area to test it well. It's been unseasonably (brutally) cold here some days, mixed with many other forms of inclement weather, so I haven't wanted to walk around outside with a circuit board and laptop, especially at night which is the only time I have to really work on things. Luckily I'm off work today on a three day weekend; I'm going to need every minute of it.

When I did a cursory test of the GPS in a park several weeks ago, I tried to test the minimum resolution of the GPS by standing in a location, and walking a few meters to see how much it changed per every meter. That proved to be futile, so I tried standing in one place, walking several meters away, and then returning to where the GPS coordinates said I should be in the same starting location. Inevitably, I ended up nowhere near where I started, even though the coordinates were the same.



Today I realized that if you leave the GPS unit facing a window long enough, it will eventually get a fix, even though you may be indoors. The picture above plots all the results returned by the GPS over a 20 minute period. (Use the cars in the picture to judge scale.) My incorrect assumption had been that the GPS might be off by several meters, but that you could compensate for that and get a stead progression of readings. The problem is that the amount it is off varies from one reading to the next, even if you are standing still. What you really get is a cluster of points near your real location. Now, the center of that cluster as a whole might be off a fixed amount, and you can compensate for that a bit, but you can't take any individual reading and apply a fixed offset and say "ah, this is where I am". It's more like darts shot at a dart board. Also, the cluster as a whole eventually shifts over time - twenty minutes after this screenshot was taken, the GPS began giving readings further down and to the right.

So, where does this leave our navigation algorithm? Since the data is statistical, maybe our control routine should be as well. Instead of doing 90 degree turns and full stops every time a new reading puts us 10 meters left or right of where we thought we were, maybe lots of readings should have an aggregate effect on the direction of travel. For instance, if we're heading N, the first time we get a reading indicating we should really got E, we won't head directly east but instead shift our heading slightly NE. Maybe the next reading comes in affirming a northerly course, at which point we head N again; it would not be until several readings confirm "go east" that we completely turn N -> NNE -> NE -> E.

Oh and did I mention the compass sensor that tells us whether we actually are going north or east is also not 100% accurate? Guesses stacked on top of guesses...

Giant Robot Headed for Colorado

Woot! We're going to Colorado! Sparkfun.com is hosting an Unmanned Autonomous Vehicle contest in their parking lot in April. This is exactly the kind of contest my powerwheels robot is designed for!

When I first read about the competition, my first reaction was "of course we never have anything like this in Oklahoma." Then I thought, damn it, after all the cool robot events I miss out on because they're in Seattle, or California, I'm sick and tired of getting left out just because I live in the sticks. I'm going to this one. Colorado isn't that far.

It's funny because you could see the same thought process go on when I asked my friend Earl Martin to come with me. "Oh I'd love to go, but really I can't..." It was his wife who convinced him, "Go! Go have fun!" (Wives of geeks, take note: you may not be able to break us of the habit of taking over the kitchen table with an occaisional soldering project, or the habit of accumulating mountains of computer electronics junk, no matter how often you roll your eyes at it, but a just little bit of encouragement from you goes a long way to making us feel enthusiastic again when we need that approval. I'm indebted to my own wife for selflessly sacrificing our living room so I can have a place to work on the robot to get it ready for the contest.)

I also asked my friend Ben to come along. He's a great guy to have around, but he's hard to pin down. When I wanted him to be one of my groomsman in my wedding, he was off in England! So I don't know if he'll be available for the trip but I hope so. He said he might be able to fix me up with a mini-ITX board running Intel's open source machine vision library - very cool!

My sister Ginny also asked to come along. I had automatically assumed it wouldn't be something she would be interested in, but when I mentioned it, she asked to come along. I don't know how the transportation situation will play out because my car doesn't have a lot of room, and most of it will be taken up by the robot, but I'm sure things will work out. If she wants to go I certainly don't object and who knows? We might turn her into an engineer, by osmosis.

Meatloaf Recipe

This is a meatloaf recipe that sort of just evolved out of cooking experiments done by my mother and myself with the help of my brothers and sisters when I was a teenager. We (especially my mother and I) are not big on measuring, so everything is approximate, guessed on what looks good, and seasoned to taste. Sometimes it comes out really good and sometimes really awful, but either way, we never make a bland meatloaf!

In a large pyrex bowl, crush 3 large handfuls of Kellogg's Cornflakes to powder using your hands.
Add:
1/4 teaspoon black pepper
1/4 teaspoon salt
a dash of parsley
a dash of sage
1/2 teaspoon fresh thyme
1/2 teaspoon fresh rosemary

Mix these dry ingredients together.

Then add:
2 cloves minced garlic
1/3 of a whole onion, chopped
1/3 of a whole green pepper, chopped

In a separate bowl, beat 2 whole eggs
Add the eggs and vegetables to the dry ingredients in the pyrex bowl, and mix

After mixing the other ingredients, only then add the hamburger. How much hamburger? I dunno - enough to fill the bowl! The key to making good meatloaf is to handle the ground beef as little as possible. It's already been ground up, and if you mush it around too much mixing it, you'll end up with a meatloaf the consistency of canned cat food. A good meatloaf has the same texture as a grilled hamburger patty.

To mix the meatloaf right, first pull the hamburger apart while breaking as few "strands" as possible. Then fluff the mixture almost as you would if you were mixing butter into popcorn. The goal is distribute the seasonings and vegetables throughout the meat, not to homogenize it. Don't push the meat back together as you mix it; we'll take care of the density by packing it down when we actually put it in the pan.

Place the mixed meatloaf in the pan, and pack it down as solidly but don't smush it. Set aside.

In another bowl, mix the SECRET sauce:
1/2 cup ketchup
1 heaping teaspoon brown sugar
two dashes of chili powder
a hint of nutmeg
a heavy dash of black pepper
1 clove of garlic, ground to a paste
a sprinkle of fresh rosemary, crushed and torn
one drop of yellow mustard

The sauce - I just made that up. Tastes great. Tangy, like teryaki sauce. Melissa's grandmother had suggested the brown sugar and mustard.

Pour the sauce over the top of the meatloaf and spread evenly.

Preheat oven to 350 degrees and bake 1 hour or until firm. If it isn't delicious, don't blame me - you must be doing it wrong. :D

PROP6502 Laptop Project

I made a laptop. It won honorable mention in the Parallax 2008 Propeller Design Contest. The point of the contest was to do something that shows off the unique capabilities of the Propeller microcontroller. I made a 6502-based laptop that uses the Propeller as its "chipset". I started with a toy laptop, and replaced all of the electronics with my own design to make it into a real working computer.

The screen is a 5.5 inch LCD TV for the laptop screen. The video decoder board, which was piggybacked on the LCD, made too tall a stack to fit inside the screen. After watching this presentation about modding by Benjamin Heckendorn, I decided not to try to make the laptop thicker. He gives the advice that you have to pick a height constraint and stick to it or else your project will grow to be "the Marvel Mystery House." Instead I figured out a way to unfolded the TV circuit board flat and place it below (not behind) the screen. Unfortunately that makes the LCD sit very high up the lid, so I made a nice decorative faceplate to distract the eye from how high and small the screen is.

The battery holder is embedded face up in the bottom so I wouldn't have to fashion a battery cover; the lid keeps the batteries in place when the laptop is closed.

Inside the laptop: at the top of the picture you see the back of the keyboard. In the second row, components from left to right: the keyboard decoder, back of the battery holder, and the CPU board. (More on the CPU board in a minute.) This toy laptop had a QWERTY keyboard, but it was not PS/2. Decoding this key matrix with the Propeller would be a waste of I/O pins. I realized that all keyboards are key matrices, including standard computer keyboards. So I simply cut the circuit board out of a real PS/2 keyboard from a Dell PC, and soldered the toy keyboard to the PS/2 board! The fact that that actually works (it does work!) is hilarious. Of course the key codes generated will be different; for instance pressing "A" might make the PS/2 board think you are pressing "X", but I simply translate the keycodes in software.

The laptop is based on a 6502 processor. I used the Propeller microcontroller as the "chipset" for the computer. The Propeller provides video, I/O, and memory control. The 6502 addresses a 64K static RAM chip, and the Propeller manipulates the control signals in order to load the initial program and monitor the address and data buses. Reducing chip count was key to making this board fit inside the laptop shell.

The reason I was able to do it with so few chips is a combination of the Propeller microcontroller's versatility, and a neat timing trick that allowed me to multiplex the data bus. After reading how old 6502 computers interleaved video access with processor accesses on the same bus, I realized I could use the same technique to allow the Propeller to access the bus in the interim period between each 6502 bus cycle. Since the 6502 puts the address out before the data is read or written, the Propeller can quickly transfer the 16 bit address onto the 8 bit data bus in two transfers, and still finish in time to return the data bus to a "normal" state so that the 6502 never knows anything happened.

What I learned from this project is that pins and signals are ways of dividing up the physical dimensions, but you can also think of time as a dimension that can be sliced up and parceled out. Making use of this extra dimension in a design can allow you to fold a complex system into a smaller physical space than it would seem to fit.

Once you've pared down your design, you've still got to wire it, and even a simple computer involves a nightmare of wiring. This part is harder than choosing the right chips to wire in the first place!

In a closely packed board, you can have a problem wiring it just from the sheer mass of copper packed into each square inch. I used strips cut from 80 conductor IDE ribbon cables to wire up the board. (Credit to Benjamin Heckendorn for giving this advice as well, in the same presentation I mentioned above.) These extremely thin IDE cable wires allowed me to pack more wiring into a smaller space, and it makes the wiring neater when you can group 4 or 8 together into ribbon cables.

This project gave me an excuse to finally use my Fluke 9010A Microcomputer Troubleshooter (pictured, front and center). My friend and former teacher, Earl Martin, once told me there were only ever two pieces of electronics equipment he wanted his whole life. One is a multichannel logic analyzer; the other is this Fluke 9010A, which he gave to me.


What this unit allows you to do is plug in to the CPU socket of a computer and exercise control of any aspect of the computer. You can test bus signals, read/write memory, even run programs and break on conditions. Technically it's an in-circuit emulator, but that term doesn't begin to cover the depth of what this tool can do. I would not have even attempted this project without it.

I had hoped to get better than honorable mention, but at least I'm on the same web page with the other winners, and received a $100 prize. I took the prize payment in the form of $100 of Parallax electronics components. I used the prize from this contest to buy parts for my project for next year's Propeller design contest: Norbert 2.0, a Propeller-controlled mobile Lego robot with a 5-degree of freedom manipulator arm. See you next time!

Success at Last: Wireless on the Freerunner with Om2008

Since I lose the USB network device when the Freerunner powers down, it would be helpful if I set up Ubuntu to automatically reconfigure the device when it does come back online. I haven't tested if that would unstick a frozen SSH session, but it might. Unfortunately I read Ubuntu has a bug that makes the reconnect not work.

The fix isn't exactly hard but before I did that, I decided to give my Freerunner's wifi configuration another try. It turns out the reason I couldn't get wifi to work before was due to a really silly thing. In the new keyboard app in Om2008, it shows what word it thinks you're typing, but it doesn't actually enter it unless you tap on the word. Whenever I tried to enter my WPA password, I would see the word suggestion from the keyboard app right below the blank password textbox, and I thought I was typing in the password box. Actually I hadn't entered anything yet because I didn't click on the word. Once I figured that out, I was able to connect to my wifi network.

But how to be sure that I was connected? I hit upon the idea of going into my router configuration to see if it had assigned a DHCP address to my Freerunner. Sure enough, there it was, and now I knew what IP to type in to ssh to it. Having wifi working solves some of my problems I had with USB networking. Even though my ssh session still freezes when the Freerunner goes into standby, the ssh session also unfreezes when I wake the phone back up, so I can continue where I left off while working. Still trying to figure out how to fix the shutdown problem.

Once you have wifi connected, you should be able to ping internet IP addresses, but DNS doesn't work yet because the Freerunner doesn't know your DNS server. I followed the instructions from the USB networking page to set up DNS, using the address of my router, as that part of the instructions works equally well for wifi networking as it does for USB networking.

Once DNS works, then the package manager works. I still haven't figured out the suspend problem.

Update: I must have missed that in the known issues for Om2008, they said that the builds from the last days of August (which I'm using) have to have the X screensaver disabled. The fix is to run the command "xset s off". What they didn't mention (and since it's a wiki, I was able to fix it for them :) ) is that you can't run xset from the ssh session, you have to install the terminal app (after getting DNS working) and run the command on the phone itself.