All posts by Matthew Gillespie (admin)

A New Look for Wireless

I’ve done quite a bit in the past few months with the neighborhood wireless project.

First off, I’ve moved everything from the Linksys WRT-54GTM devices to an Engenius EOC-2610. The system Atheros AR2315 based. (More pictures here)

An Engenious Naked. Totally hot.

The firmware is still OpenWRT kamikazee (I dumped DD-WRT a while ago on the 54G’s), with a patched version of the NoDogSplash captive portal  (to prevent the graceful exit when a null token is submitted, also to support a “Magic token”, since I don’t truly care about it being the same one issued during the pre-authentication phase).

The only lingering issue relates to my version of the hardware not handling a reboot, which is a known issue apparently related to the kernel’s watchdog driver. There’s already a patch out there, and I plan on implementing it soon. (At present, an “init 6” will simply cause the unit to stop responding – requiring an actual powercycling) The good news is that I’ve never had to actually reboot the device for any reason.

Other installed packages include NProbe for Netflow export and  SNMP for monitoring/graphing purposes. In all honesty, the build is rather simple but effective. It’s also waterproof – the Engenius EOC-2610 is built for outdoor use – complete with waterproof housing and PoE support (albeit based on the warnings on the PoE injector, I don’t believe it’s 802.3a[ft] compatible)

As of this morning, we’re up to 13 users in the neighborhood. Shortly, I’ll be lighting up the Eastern portion of the neighborhood, which will provide access to a larger number of users.

Oh, and there’s a new look to the portal:

The new Midtown WiFi Theme

The new look is a slight modification to the Lorea Hub Theme, with additional imagery from istockphoto.com.

Music: Ripping and Audioscrobbling

I’m a big fan of Last.fm – a social networking site that allows you to stream audio and share your music interests with others.

The LastFM Social Site

You may have noticed the inclusion of my recently listened to tracks on the bottom right side of this screen:

My recently listened to songs.

One of the major benefits to LastFM is it’s API – instead of being tied down to using only the LastFM player to ‘scrobble, I can use pretty much any open-source audio player I want  – and still share my recent tracklist with others. (Googling “pandora API” reveals that as of a few months ago,  Pandora has yet to release an API)

The LastFM player

The open API has allowed a number of really nice applications to be developed – you can AudioScrobble from an IPhone, a BlackBerry, graph your listened-to artists history, etc, etc…

Personally, my most commonly used item is one of the most minimal: an MPlayer CLI wrapper used in conjunction with LastFMSubmitD. This allows me to run my player behind a screen and ‘scrobble at the same time. (And running the player behind a screen gives me the freedom to bounce in and out of X)

MPlayer behind a Screen

Over the years, I’ve been slowly working on digitizing all of my audio library. Initially, I was doing the process using only LAME (especially since I generally prefer a command-line tool for most things), however not having anything to add the ID tags to tracks, I finally migrated to using GRip.

Grip and the Velvet Undergound

Grip allows you to set whatever format string for filenames you want, handles the CDDB lookups and automates ID3 tagging. I generally don’t use the audio player, but it’s there also.

My overall goal is to install an outdoor speaker system in the next few weeks and have my WebpadDT streaming my entire audio library over the wireless from a control point in the kitchen.  The Webpad is ready, the library is 1/3 ripped, now it’s time to find some good speakers.

Password Manager

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.

Home layout: Layer 2

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”