Posted by: | dragorn |
---|---|
Subject: | packetracker.cc - recording lat/lon signal trace for each network + valid fix duration |
Date: | 13:45:44 19/06/2008 |
> I'm interested in writing a script to better determine the location of APs. Does anyone know how to log the signal strength of *each* packet so that I can sort by AP and try some different methods to estimate it's true location?
>
> I can't seem to find anything looking through the docs or code (not very extensively mind you). I want more than just min/max lat/lon, I want *all* the points and the signal/noise at those points for each network.
>
> It looks like I can do this by modifying packetracker.cc's Packetracker::ProcessPacket to record a BSSID,lat/lon,signal,noise tuple somewhere but I was wondering if there was an easier way.
This is what the gps xml file and gpsmap are for, it already does all that - per packet positional logging, and smarter attempts to guess location w/ a full data set.
Expect a commit of kismap soon, a python replacement for gpsmap.
> One other question - while processing packets I see packetracker checks if there's a valid fix, does anyone know if Kismet or gpsd sets that flag to invalid in between fix moments - IE ~100ms or so on either side of the fix - or do we just continue to use one fix until we get another.
Kismet uses whatever gpsd provides.
Gpsd does whatever it feels like - depending on the version it can thrash between 2d/3d fix on a solid 3d due to how it handles jitter & the requirement that individual applications be rewritten to send extra commands to solve this behavior. Older versions erroneously report no fix on some nmea streams, etc.
Recent kismet releases use a combination of trying to enable anti-jitter in gpsd and externally doing jitter correction, requiring two fix values in a row to match before assuming they are valid, and otherwise using the higher of the values (ie 2/3/2/3/2/3/2/3 == 3, while 3 3 3 2 2 2 2 2 2 == 2) meaning if your gps really IS losing the 3d fix and hopping between 2d and 3d, Kismet will lag about a second behind.
There will never be more than a second precision between kismet/gpsd/your gps, and sometimes precision may be several seconds, depending on jitter correction and other randomness.
-m