Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:What source captured the signal?
Date:11:03:09 12/09/2008

> Thank you for the speedy reply. It's good to have an active developer who is willing to field stupid questions.

Nah, this one wasn't stupid :)

> So if I understand you correctly, the uuid can be parsed out of the PPI log output of the Kismet server? I haven't had the chance to test newcore yet so I may be able to answer this myself once I have time.

Currently no, but the PPI headers are a flexible tagged field format, which could allow for per-packet tagging of the interface that saw it, though in the copy of the spec I have that isn't currently defined, so I'll have to bug them about it. If nothing else it can be carried in the XML data for the network that kismet exports.

> Also, I believe I read that you said the uuid is a created based on the time, mac address, and a random number. I believe you also said that since that's the case, it'll change once the listening device is rebooted. Is there a way to extract the mac address from the uuid?

Once I finish the packet source changes, Kismet will cache the UUID for source interface/name pairs and re-use them.

Currently the way to extract information about the source given the UUID is to listen to the *SOURCE protocol from Kismet, which gives per-source stats at regular intervals. It's not logged into the data files, though it might make sense to change the netxml file into a more generic kisxml file which logs more information about the running state.

> I'm not a developer/programmer so I apologize for my lack of understanding. Kismet is very close to being a distributed opensource WIDS solution if the whole listening source can be tied to the findings. Once that's accomplished, it's trivial to throw that stuff in a database and query it. There just isn't anything else out there in the opensource community that gives the functionality of kismet. I've searched for a solid two weeks for an opensource, distributed listening agent WIDS and have come back to Kismet every time.
> Wardriving is fun but kismet is so close to being a kick-arse intrusion detection tool as well.

That's exactly what I've been attempting to solve w/ the newcore rewrite - maintain the current wardriving functionality but expand it to be a more persistent system. The newcore alerts system has also been expanded to provide better information per alert raised in fields (ie the alert network protocol now exports the alert type, source of the packet, dest, bssid, channel, and then the free-form text).

Once I fix my local codebase (which is pretty pureed at the moment, 5k diff from svn) I'll look at how source tracking is handled. It would also be trivial to add packet sources to alerts, so tapping the network protocol off kismet would give the UUID of the source.


Reply to this message