Category Archives: Wireless

New Wireless Toy

I’ve really been enjoying the feedback on the free wireless access from my neighbors. As always, everytime I start a new hobby, I end up with a handful of new toys – and I got one just today:

The Wi-Spy 2.4x

The Wi-Spy 2.4x is a portable USB spectrum analyzer for the 2.4Ghz range (They have other models that cover 900mhz and 2.4/5Ghz). The 2.4x model includes an external antenna (SMA), whereas the 2.4i has an internal antenna only.

The Accompanying Chanalyzer software

With the use of a wireless card, one can overlay SSID’s atop the channels in the Topographical  graph and determine what radiation  belongs to which Access Point. The bottom graph (Planar view) allows one to view which Zigbee channel, wifi channel, or frequency range is most in use.

There’s a similar device on the market which is substantially cheaper, the Airview,  manufactured by Ubiquiti Networks (~$39 vs. ~$160), but from what I’ve seen, the Chanalyzer sofware in use with the Wi-Spy appears to have more features (the ability to record your captures, the ability to overlay RF “fingerprints” of various devices atop your captures), etc. The Airview software is written in Java (Read:  supported in Linux), whereas Chanalyzer is written in .NET (good luck with that one under WINE).

There are Linux tools for use with the Wi-Spy (Spectrum-Tools) which I can defnitely appreciate,  but again the recording/playback and fingerprinting along with SSID overlays really make Chanalyzer nice. (For the record, you can actually record the data using one of the tools in the Spectrum Tools suite… I don’t believe you can playback easily though)

Spectrum Tools: from the author of Kismet

I’m supposed to be working on a number of other things at the moment (studying for an exam being the major item on my to-do list) so unfortunately this post is more of a “guess what I just got” as opposed to a “look at what this can do”.  In the next few weeks, I plan on picking up an AirView also, and will provide a side-by-side comparison of the two.

In the meantime, check out this video advertising the Wi-Spy, and if you have any experience, recommendations or thoughts on it or the AirView – hit me up in the comments.

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.

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.