the jof

My employer outsources their HR. Part of the services they provide are flash-based courses for mandatory training.

Humorously from the Cultural Diversity applet:

And of course, you should be using IE, it’s the browser.

iperf is a tool I find very useful on a regular basis. For those unfamiliar, it’s a CLI-based tool to push test traffic around. It can flexibly generate a lot of TCP or UDP traffic.
I mainly use it to tweak TCP parameters for maximum transport-layer performance or to gain a rough measure of the available throughput available for a given network path.

Or it can be timed to make funky bandwidth graphs:

I’m sorry to those who make use of my open wifi. It will be down for a couple of days while I work on designing and testing a new network implementation. Once it’s done it should have some cool new features:

1. Routable IPv4 addresses assigned using DHCP (just like a regular dynamic IP most places nowadays)
2. Routable IPv6 addresses assigned using RA (a standards-based stateless autoconfiguration protocol for IPv6, well-supported)
3. Using DHCP option 81 to have a DNS subdomain point to your current address (so let’s say you tell the DHCP server your name is ‘banana’, an A record will be added for banana.wifi.thejof.com pointing to your new IP)

Some features I would like to add in the future:

1. DHCPv6. This would make implementing the DHCP-DNS setup as described above possible for IPv6 as well
2. Dynamic firewall configuration. I’m thinking of a web portal to configure how the client IP is firewalled.
3. Some privacy controls and tools. Maybe having a local tor and/or privoxy server for users to use. Depending on if I can secure it’s use, maybe a pool of IPs from which users can pick a new random address.

Lately I’ve been playing around with a 3×3 Rubik’s Cube. It’s fun to have something to poke at while waiting for the muni.

I think that I’m at about imtermediate level. I’ve got the basics down, and now I’m just trying out some quicker algorithms. Best time so far - 2:25

Cisco creeps me out. I think it’s how successful they are somehow affirms my suspicions that they’re plotting world domination or something. I mean their hardware is *everywhere*. I can even state as a matter of fact, that if you’re reading this soon after it was written, you’ve already had these very packets fondled by no less than four Cisco boxes.
It starts to get scarier when you think about all the other things that are handled by Cisco hardware - ATM transactions, merchant transactions, phone calls, both mobile and fixed data, or even CCTV cameras.
They’re all closed source and “standards” compliant. It just seems weird to me.

Creepy hardware aside, I’ve always been a secret fan of Radia Perlman. She’s been a huge driving force in network and network security protocols for a while now. What I like best about her work is that it’s written with a certain grace about it. It always stood out to me among other networking papers.

I’ll just leave you with the cute headers from this piece of municipal (sp/h)am. The reverse-path seems to indicate some legitimacy as well:

Received: from smtp1.sfgov.org (smtp1.sfgov.org [209.77.149.26])
by sfo.thejof.com (Postfix) with ESMTP id AF2ED10804EA
for <XXXX [at] thejof.com>; Tue, 29 Apr 2008 18:15:15 -0700 (PDT)
Received: from DOE-MIS04XP (client-172-31-01-185.ci.sf.ca.us [172.31.1.185])
by smtp1.sfgov.org (8.12.11.20060308/8.12.11) with ESMTP id m3U25GAB030779
for <XXXX [at] thejof.com>; Tue, 29 Apr 2008 19:05:16 -0700
Message-Id: <XXXXXX@smtp1.sfgov.org>
Reply-To: San Francisco Department of Elections <sfelection@gmail.com>
From: San Francisco Department of Elections <sfelection@gmail.com>
To: Pollworkers <XXXX [at] thejof.com>
Subject: A Message from the San Francisco Election Department of Elections
Date: Tue, 29 Apr 2008 17:57:42 -0700
Importance: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
X-Mailer: Mach 5 Mailer version 4 RI{d6cb4-f2cec}
Content-Type: text/plain;
charset=”Windows-1252″
Content-Transfer-Encoding: 8bit

Dear Voter:

…

We have a decent out of band remote access setup here at work. That’s basically a backup way of connecting to our network just in case something so catastrophic should happen that our entire edge and core network become unavailable from the outside, we can still connect through other means to administer devices through an internal subnet.

Basically, this is just a DSL connection from a different (and much bigger) ISP. While this is probably good enough for just about anything that I could possibly imagine, I think it could still be improved on.

Basically, I can think of three major failure modes: power loss, internal layer 2 network failure, and layer 3 transit failure. All three could be caused by operator error, a break in an infrastructural component, or some combination of failures likely to happen in the event of a major catastrophe.

If something should go awry, three things need to be in place in order to connect back: remote access devices need to have electrical power, they need to function as intended (i.e. the configuration should be as idempotent as possible), and they need to be able to reach the devices they’re there to manage.

At first I’m thought of something like this:

However, I think I could probably improve on this in a few ways:

• Reduce complexity by using some kind of embedded box rather than a full-blown computer. They draw a lot less power and they have less components to fail.
• Increase power redundancy by using a dual-feed switch to both feeds on both machines. I suppose this eliminates the failure mode of one power feed failure in combination with all transit and just one POTS provider going down
• Greater layer 2 interconnection to many different parts of the network rather than just two points of interconnection

I’ve finally gotten around to moving my site to my new network. This is a much more permanent home and a much better machine to boot.

I’ve also been pretty lousy about writing often lately, and frankly I’m over it. I’ve been putting off actually publishing anything because I feel like all these posts I’ve been poking around on for ages just aren’t developed to completion. Well, I’ve realized that’s just silly, so I’m going to just hit publish a little more often.

I just got LinuxBIOS working on my desktop at work, and can I say, “This is awesome”.

Basically, it’s a drop-in replacement for many proprietary BIOS firmwares. No more nasty, unreliable (at least on today’s drives) floppy disks booting DOS just to bit-bang some memory address with some new firmware. I’m fed up with that crap. Not that I ever really have to do it often, but anyone who’s ever done it in recent years knows just how sucky the process can be.

Anyway, the install was the easiest thing ever. First, I checked out the info-packed LinuxBIOS wiki to see if my motherboard was supported, then just grabbed the latest code from SVN, ran make for the flashrom tool, and I was off to the races.

The first thing I do in the morning is come in and swap out the backup tape from last night and put in a freshly rotated one for that night. Then I begin booting and I get some coffee and a glass of water and come back to check the production server logs for errors. Next comes email which includes the output from the cron job that ran the backup last night and check what was done and how efficiently. There’s also the occasional alert email about something going wrong elsewhere. Then I begin plotting things I want to get done that day in emacs.

After that I begin making the rounds in the office to check in with users and see if fixes from the day before are working for them. When I make it to my desk after that, I check on the firewall logs from yesterday to make sure nothing fishy has been happening, and that things are generally ok.

It’s usually at this point that printers start exploding.