I’m still amazed at the frequency in which I see someone in the IT field open up a M$ Word document or spreadsheet with all their passwords in it. What’s even more baffling is often times they’ll store this password file on a shared drive – shared with all members of the company or group.

For years, I used PWManager to store the hundred or so passwords I needed access to. Like most password managers, you have a database file with a master password.  The master password pretty much unlocks everything.

This was PWManager

I really liked PWManager. There were obvious things missing – most importantly a command line or NCurses based way to access your password database. Overall though – I always found it to be solid.

Unfortunately upgrades to my workstation in the last 12 months have rendered it practically useless. (Gentoo went to KDE4, unfortunately PWManager was written for the KDE3 libraries)

I’d searched for a while, evaluating a few open-source password managers before finally settling on KeePassX.

This is KeePassX

KeePassX is based on the QT4 library, has decent search features, and really expands upon what PWManager provided.  When I initially migrated to KeePassX, the one thing that bothered me was the missing “systray-like” ability to right-click on the minimalized application icon, manuever quickly to a group, then username – and copy the selected password into the clipboard.

<Dog learning new trick>In the end, the KeePassX search bar really does provide a quick way to accomplish the exact same thing.</Dog learning new trick>

When you’ve highlighted an entry (after searching for it),  CTRL-B copies the username to the clipboard, CTRL-C copies the password to the clipboard. You can also set expiration dates for passwords, associate URLs and comments to each entry, and select unique icons for various passwords.

Another benefit to KeePassX is its ability to import database files from other password managers. It should be able to import KWallet and PWManager files, although I found that import process didn’t work properly (“Compressed files are not yet supported” when trying to import from PWManager) . Thankfully a former co-worker already scripted the conversion of an exported PWManager CSV password file to a KeePassX XML file, which can then be imported with very little issue.

KeePassX also runs on OSX, Windows, and Linux. (I used to have issues occasionally where I’d have to reboot my dual-boot machine to grab a simple password from PWManager – but not anymore). The cross-platform support also means that I can now share a password database with my girlfriend (which makes paying online bills much easier)

I’d seriously recommend KeePassX to anyone saving their passwords in an easy to read text-file. It’s easy to use, pretty, and it gets the job done. Of course, I’m all ears if someone has a better password management system they’d like to recommend.

I’m just finishing up a CCNA preparatory class at the local community college (I had no idea what to expect on the exam, so thankfully I stumbled across this class). I’d definitely recommend the course – the instructor (Shawn Cannady) has done an excellent job covering a wide volume of material in a rapid pace.

One of my classmates recently asked about how I was segmenting off the public wireless from my home LAN. As VLANs, VTPs and PPP were subjects covered in the course, I wrote the following article for the class Wiki:

In the United States, many (but not all) providers use PPPoE to establish the layer 2 connection over ADSL. The upside to this method is increased accountability/manageability, as well as the ability to resell the connection to 3rd parties (For non-resold lines, Telcos are shifting to DHCP-only connections however, as there’s less overhead involved)

Background: Many smaller ISPs use the local Telco DSLAM equipment along with dedicated circuitry and L2TP tunnels back to the smaller ISP routers – which terminate the PPP sessions. In such an instance, connections are routed to individual ISPs based on the realm in the authenticating username [username@realm.com/password]. The smaller ISP can then use their ARIN assigned network to assign globally routed IP addresses.

Working for such an ISP, I often take advantage of this setup – creating new PPPoE username and passwords on our system for individualized connections. Instead of having 3 separate ADSL lines for 3 different Internet connections, I use 1 single ADSL line for 3 different Internet connections. Each “unique” connection has it’s own PPPoE username/password and IP. (The only downside: Each connection shares the bandwidth of the 1 line).

The upside to this configuration is the isolation of Layer 3 – not all connections pass through the same router on my end of the connection. They do, however, pass through the same switch(es) and ADSL modem (however, at layer 2). Instead of worrying about access-lists to prevent different subnets from communicating with each other, I simply worry about inbound traffic from the WAN side on each connection.

My current home layout (simplified here) contains 2 switches. Switch A is located in my office, while Switch B is located where the phone line enters the upstairs. VLAN 2 connects devices directly to the ADSL modem. VLAN1 connects my home LAN to the LAN ethernet of my main home router.

In the above layout, any device connecting to the DSL Link (members of VLAN2), must maintain it’s own PPPoE link to be able to access the Internet. (To simplify this image – imagine that the Wifi router is plugged directly into the DSL modem and configured to connect using PPPoE. Then, imagine the same thing for all members of VLAN 2)

An 802.1q trunk allows the server in my office direct connection to the ADSL modem, and allows my office LAN to connect to the main router (which in turn, routes traffic out the WAN interface PPPoE connection). There are numerous other devices on the LAN.

But why do this???

When I initially decided to provide free wireless access to my neighborhood, I had a few requirements. First of all, I did not want my neighbors connecting to my home LAN. Second, for liability reasons I wanted to the free WIFI to have it’s own globally routed IP address (not an RFC-1918 address NATed with my home static IP). A third requirement was the use of Netflow version 9 to collect various headers from each packet and frame (but not the data payload itself) in the event someone attempted something malicious or a user had major virus issues.

In addition to the WIFI access, on occassion I run dedicated honeypots and malware collectors – obviously servers you want completely isolated from your home LAN.

The above layout is by no means entirely bulletproof, but the added complexity means I don’t have to look over my shoulder as much — and I don’t have to maintain access-lists just for the LAN to live in “separated harmony”

I’ve been having an issue today with a cryptic (which seems to be the norm for Microsoft) error message. Well, actually it was just an error number:

-1072896658

I was in the midst of adding some minor AJAXified code to a corporate website. The test site works perfectly, however whenever accessing the javascript Object/member xmlHttp.responseText on the release site, I get that magical number of death.

Thankfully Pavan Keely had already done the research on this one – IE is wigging out due to Charset issues. Sure enough, the apache directive “AddDefaultCharset” was set to none. Fixing that, fixed this annoyance.

As if I don’t have enough going on already (school, lab, work, numerous hobby projects, cigars and Tom Waits), I’ve begun modifications of one of those small radio-controlled helicopters using a PIC16f628A microcontroller.

I’ve done something similar with an radio-controlled car in the past (very basic “go forward, turn, go forward, back up” stuff though), but that was 5+ years ago.  My goal this time is to code a program allowing the helicopter to lift-off, turn in search of the brightest source of light, and follow it. (Have you ever seen Sea-Monkeys go crazy over a flashlight? That’s my goal here, but with a helicopter)

A lot has changed in 5 years.  The last time I worked on a project like this (as basic as it really is), I was using a PIC IDE on Windows 2000 (something I’ve since misplaced). I was also using the PIC16f84A then, a chip that’s since become less than favorable (less memory, needs an external oscillator)

Having migrated entirely to the Linux operating system (aside from a dual-boot laptop for school), I went in search of a decent C compiler and simulator – and I really lucked out.  SDCC and GPSIM were exactly what I needed. (I have to give Micah Carrick a big thanks for his article that steered me in this direction)

My Desktop running GPSim and some test code

SDCC is simply a Small Device targetted C compiler, so I’m not going to go into in depth  here (see Micah’s great article above).  BUT I did have a major issue getting it set up initially:

The problem I experienced with SDCC was that the Gentoo Portage distributed version is 2.5.6 (as of March 2010).  Unfortunately, memory locations for individual pins on PORTA and PORTB on the PIC16f628A aren’t defined in the header files in 2.5.6. Usually, one can access them via RB[0-7], etc… So my advice is this – use the subversion distributed version of SDCC (which is presently 2.9.7)

My second issue getting set up  was with GPSIM. I’ve not had a chance to delve into the reasons, but for some unknown reason the version 0.23.0 and 0.24.0 wouldn’t play nice with any controller I tried:

gpsim -p16f627 -c testcode.stc

gpsim – the GNUPIC simulator
version: Release 0.23.0

type help for help
**gpsim> SimulationMode:51
FIXME gui_breadboard.cc Build
WARNING: command line processor named “16f627″ is being ignored
since the .cod file specifies the processor
WARNING: Ignoring the hex file “testcode.asm”
since the .cod file specifies the hex code
RRR gui_breadboard.cc:createLabel p16f627 11 42
Disabling WDT
FIXME: HLL files are not supported at the moment
**gpsim> running…
attempt write to invalid file register
address 0x10a, value 0×1
could not decode trace type: 0×0
0×0000000000000066 p16f627 0x00FC 0x008A movwf pclath
Read: 0×0001 from W
Invalid Trace entry: 0×0

After flailing around trying to make gpsim happy, I finally downgraded to 0.22.0, finding that I had no issues with it.

GPSIM has some nice features – stopwatch, available breakpoints,  simulated oscilloscope probes, the ability to lay out basic logic circuits, simulated LEDs and pushbuttons, etc

Simulated Scope Probes

Ok, so now I’m all set to develop. I’ll post videos of the helicopter before and after modifications, as well as a before and after test-flight shortly.

Update: 3/28/2010:

Rob Pearce has infomed me that the issue above (regarding 0.2[34].0) has been now been fixed in subversion.  While writing this article on the road, perusing the bugtracker (or reporting the bug) somehow slipped my mind – my bad. Kudos for the quick response time (once someone actually bothered to report it).

In any event, this article is meant to point out an excellent tool. Have a look at it.

I’ve been planning on building an APRS beacon into my car for some time, initially contemplating using a WebPadDT + XASTIR to do the work, but that idea quickly posed an issue – the WebPad was too big to reasonably it in the car with another passenger (at least in my car).

Yes, I’m well aware that APRS is not really meant as a vehicle tracking device, and in many circles it’s frowned upon.

I’ve enjoyed working with PIC microcontrollers since I was first introduced to the 16f84A years ago. But in all honestly, I’ve not done more than “blinky lights” and very basic modifications to an RC car with them. (Take a look at a great article to get started working with PICs)

Byonics has a cool kit – the Tiny Track3+. Figuring I’d use it as a chance to exercise my soldering skills (which need a bit of work), and liking the fact that I wouldn’t have to hunt for each individual component on my own, I picked one up (with GPS unit).

The project build steps are extremely well documented. Literally, every step along the way is fully explained along with color images in the downloadable PDF. Build time takes under 1 hour (actually closer to 30 minutes, although I incorrectly soldered the female DB9 connector to J2 and had to waste time de-soldering it).

Prior to installing the accompanying PIC16f628A chip, I made sure to back up the currently running software (these chips are dirt cheap, and I’m not entirely sure Byonics will just give me the software if I ever have to replace the chip) Looks like my old serial programmer still works (remember – the USB to serial adapters generally don’t put out enough voltage to program a chip, so make sure you have on-board serial):

Old serial PIC programmer

After backing up the code, I pop the chip into place on the TinyTracker, and voila -the finished product looks like this:

TinyTracker3+ Fully Assembled (I'm using Lysol in my coffee since I'm out of Half and Half)

The Byonics crew have also written software to configure the TinyTracker. Luckily it runs under WINE so I didn’t have to reboot. To configure, power the J1 DB9 connector with a 9volt battery.

TinyTracker3+ in it's case, being configured serially

And run the configuration program (again, it’s fairly well documented in the manual):

After being hung-up in customs (and a brutal snowstorm), I finally got the radio component of my APRS system – the FD-150A (It took almost a month to get here from Hong Kong)

The output voltage  on the FD-150 battery is ~6.25V, too low to power the TinyTracker3 (which requires 7+V). A voltage multiplier would probably fix that, but my overall goal is to encase all components in a NEMA style box, powering it off the car.  So for the rest of the testing period, I’m using an external power-supply.

Hopefully in the next few weeks, I’ll have time to finish the entire setup. Keep checking back, I’ll post updates when I can.