www.storm.net.nz

[ / ] [ Metlstorm ] [ Projects ] [ ice.storm.net.nz ] [ \m/ ]

Projects
[ Security: SSH 'Jack Hai2IVR MAFL-Load Firewire, DMA & Windows Asterisk Remote Root Metl-o-UnNetCrypt ] [ Wireless: Metl Kismet GPS Plotter - Google Earth Edition Metl War Tri Pod Metl Kismet Client Metlstorms Kismet GPS Plott0r Metl Helix Wireless Grapher Metl Network Recon Visualizer ] [ Home: Rotoseat Noise Weblstorm Viewtron CharGrill ] [ Abandonware: Obscured By Clouds ]

Metl War Tri Pod
What do you get when you cross a lego mindstorms kit with a 14dbi yagi? The MetlWarTriPod.

MWTP is a project who's eventual goal is automated 802.11 wireless direction finding. It's of course quite a complicated project, and isn't actually usable yet, but it's spun off a number of components which are useful in their own right.

The Tripod itself exists and works well; the mindstorms runs BrickOS, and opensource posix like cooperatively multiasking OS for Hitachi H8. This allows me to write code for the mindstorm on my linux box in C, cross compile it with GCC, and uploade the resulting code to the mindstorm. Communication back to the host runs via IR, using the LNP protocol (a simple UDP like protocol with 8bit host/port addressing).

The tripod streams data back to the host, where a number of daemons listening on LNP sockets rexport or log the data. One daemon provides the telemetry data (azimuth and elevation) to other components via a TCP socket. This data is collected by a custom kismet client (which is in itself a totally usable graphical kismet client) which correlates sniffing data from Kismet with telemetry data from the tripod. Then it visualizes it in realtime, and logs data for post processing by some of the other tools.

I've written several post-processing tools; for generating antenna pattern graphs, for visualising antenna patterns and ATT in 3d, and I've begun on a 3d-geospatial viz engine. The end goal is being able to see the relationships between stations in 3d space, with wireless coverage visible as clouds. Like a network diagram, but in 3d-spinny round o vision. One day, all the components (MKGP, MNRV, MKC, MWTP, O2) will all merge into one Uber Wireless WankoVisionTron, which will do everything, know everything, see everything, and then present it all in glorious 3d. With stereo shutter glasses (I've got some old H3D ones...) or maybe BLS's VFX1 Helmet. Yeah. Headtracking! That's where it's at.
Last Update: 2006-12-18 21:34:28
State: Brewing
Distribution: Private
Tags: Wireless
Images:
Same plot as the previous shot, but rotated some, so you can see the heigh plotting. Yes, Auckland is that hilly. I dream of volumetric clouds of wireless coverage flying around in the 3d metaverse. Here's my first attempt at it. Blue hose is a GPS track plotted in 3space, (note the height data) and wireless data recieved during the wardrive run is plotted as the green sausage.  I take each packet, plot a sphere in 3space with the diameter relative to the signal-noise ratio, and then build a surface mesh of the resulting spheres (180k spheres is a lot of polygons). Overview of the MWTP project, with all the major components identified. I bit the bullet and wrote a 3d renderer for ESRI Shapefile vector datasets. It's really primitive at the moment, with no height data, but you can see the road plotting working well. The width of the roads is based on the number of lanes in the road(!) and the red ones have state highway designations. More 3dviz. In my opinion, there should be only two sorts of user interface; commandline, and full-VR-wankovision ones. More 3d-viz of the azimuth-to-target algorthm. Nothing quite like a bit of spinnyround-o-vision. One of the endgoals is to visualize the relationshipe between wireless stations in a 3d mapping environment. Here, as a primer to this, I wrote a 3d-viz engine for the azimuth-to-target datasets. One of the requirements is to determine azimuth to target from a set of packet-signal-strength/azimuth pairs. Based on our knowledge of the signal characterstics of the yagi, we can interpolate the data to obtain an ATT. Here I'm using gnuplot to visualize this process 
during tuning of the algorithm. Closeup of the tripod itself; in this picture, it's yet to have it's elevation sensor integrated.