Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Which source is my discovered wireless network on?
Date:17:25:56 01/10/2006

> I've just completed installing a number of kismet drones, and have them all configured properly and working very nicely with Kismet-2006-04-R1. They are apparently all seeing a variety of networks.
> The purpose of the separate drones is for rogue access point detection, and the drones are spread out over several buildings, across several towns connected through a wide area network.
> The problem I'm encountering is, that when a new AP is detected, is shows up in the display on my server, but I'm unable to tell what drone picked it up as a source! I've looked at kismet_ui.conf and kismet.conf to see if I'm missing anything, and I'm not having much luck.
> Aside from stopping the server, and disabling the drone sources one by one and restarting the server each time (to only use one drone at a time), is there a better way to determint the source? Part of my asking, is that if a rogue AP is discovered and is cloaked, a signifigant amount of time may pass before a client assicoates to the rogue, and thus a long time before kismet obtains ssid information....
> So, to make a long question short, is there an easy way with kismet server to determine which source an AP was discovered on?

Currently, no. Drones present a highly interesting problem -- in newcore, capture interfaces are exported upstream to the server from the drones, however there is no restriction on multiple interfaces having the same name on different drones. Each interface DOES have a globally unique identifier (using the standard UUID system which combines the MAC of the capture interface, if it has one, a time component, and a fairly high-quality random component), however these change each time the source is created -- so a drone which is rebooted will have a different UUID for the interface when it comes back up.

I've considered keeping some sort of state file in the ~/.kismet/ directory which would let it map UUIDs to names and keep a consistent UUID for the interface, so long as it exists in the state file. I'm not sure there is any reason NOT to do this, although there are interesting issues still -- strange things would happen if you changed cards but kept the same name, since any records on the server side about what sort of card it is would change halfway through.

A similar problem exists trying to define a new pcap file packet format -- adding source and removing them runtime can lead to strangeness in logging, since it would change the header and resize the front of the capture file.


Reply to this message