Category Archives: What?!

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”

The Tiny Tracker 3+ APRS encoder

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
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
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
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.

Happy Birthday webdt.org!!!

It was a year ago this month that I received a comment on the braindeadprojects  site from a user named quotaholic.

Quotaholic had also picked up a WebpadDt  with the hopes of expanding upon it’s capabilities. My initial goal was a cheap touchpad screen for a car-pc. Quotaholic was thinking about bigger possibilities – and built himself an entire community site.

So somewhere on or around March of 2009,   www.webdt.org was born.

While I don’t necessarily agree with some of the goals of the site (I personally don’t understand the point of testing to see which Linux distro’s will run on the webpad – and would like to see the community get behind one distro and build releases specifically aimed at the webpad)… the level of ambition is amazing.

I’ve not had much time to continue with the webpad on my own. Quotaholic however, has released a 100M version of Debian Lenny with the LXDE Desktop Environment geared towards the webpad (penmount drivers working and all)

So what am I doing with my DT now? Using it to stream audio (over my wireless) to my kitchen stereo. And the Gentoo Image that I’ve put a lot of work into? Well, that filesystem is on my storage server while I use Quotaholics release.

Happy Birthday webdt.org!!!

Finally Saying No to NoCatSplash

For the last 6 months or so, I’ve been running a free wireless access point for my neighborhood. In an effort to get my local community to know each other (and local goings-on), I’ve back-ended the system using the elgg social networking platform.

To use the free wifi, you have to register on the social site.

The Captive Portal

Uptime however has been a major pain – for quite some time NoCatSplash has been broken in DD-WRT. Ever since version 24 (at the very least), it’s been grouchy – all of the sudden not working and requiring a reboot (or possibly clearing and resetting the iptables targets and restarting splashd)  to fix. The wiki documents a few workarounds, but I’ve gotten tired of the overall bugs.

Initially I planned on simply fixing it, but after a little bit of thought,  I decided to give OpenWRT another look. I’m sure I could have gotten away with using the mini or micro versions of DD-WRT and adding to it, but last time I used OpenWRT’s build environment I was really impressed – so I spent this weekend working with it again.

Building your own image is simple – using the ImageBuilder system (I’m working with WRT-54G’s)  simply “make image” setting the target PROFILE and PACKAGES via environment variables. This method uses existing binary packages to build a .bin or .trx file for easy installation (via the web interface or mtd command). “make info” will give you a long list of profiles, and packages that are readily available are contained in the packages subdirectory.

Recompiling packages is extremely easy – download the SDK:

mkdir ~/devel && cd ~/devel

wget http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2

tar xjvpf OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2

If the package already exists, check it out via subversion:

cd OpenWrt-SDK-brcm-2.4-for-Linux-i686

svn export svn://svn.openwrt.org/openwrt/packages/net/<packagename>  package/<packagename>

And to compile simply execute:

make package/<packagename>/compile V=99

(On older versions it’s “make package/<packagename>compile V=99″)

After hitting my head against the nocatsplash package’s failure to build correctly, I finally opted to look at nodogsplash. “Because it will at least build” is probably not the best way to choose captive portal software, but it’s mine.

First thing requiring a fix is a bug that causes nodogsplash to crash when one sends a request to the auth-server without a “redir” GET variable being set – a bug evidenced by:

links “http://192.168.1.1:2050/nodogsplash_auth/?tok=fffffff”

Thankfully the crash is “gracefully” handled in safe.c’s safe_strdup()…. but it still causes the daemon to crash.

So – a quick patch, as well as some added “features” (including a magic token) and I’m set. Patches to source can be added to package/<packagename>/patches. Upon make, patches in this directory are first applied.

So instead of waiting around for a fix to NoCatSplash in DD-WRT, I’m moving on. So far NoDogSplash has proven effective – although I’m far from actually migrating to it (the old access point is still running for the time being). In the next few weeks I should have a custom web interface built, as well as pmacctd configured (I am exporting Netflow version 9 data to a collector as a C.Y.A measure), and bandwidth shaping properly enabled.

Custom patches to NoDogSplash are forthcoming.