|Subject:||Parsing out just clients, unassociated clients, and adding a timestamp|
I jumped into IRC yesterday but got dropped while my computer sat waiting for a response. If I missed you, sorry.
I'll give the new code a look in a bit - sounds really schnazzy. As for the current code, is this a reasonable assumption?
- Run CLIENT MAC,BSSID
- Filter lines where MAC=BSSID
- For all remaining lines, MAC indicates a client and BSSID indicates an AP
Also, I've done a bit of digging through the documentation and forums to find out what some of the fields represent - things like "type," for instance. What do these values mean, and what do they represent? If I can use them to better parse out the data and filter out the MAC addresses, that would be helpful.
Lastly, say I had a device where I wanted to get its MAC address, but I didn't want to dig through menus to find it. Is there a command I could run repeatedly to send out packets, pick these packets up with Kismet based on some signature in the packet, and thereby get the MAC that way? For instance, could I have a system send out ping requests in quick succession so I could detect the device in Kismet? (I hope that makes sense).
> If your project can tolerate the risk of some instability, by far the easiest way to do this would be to switch to the kismet git-master code; it's got a new REST-based interface that will give you JSON (or msgpack) for all of that, AND has a new method for tracking devices (specifically, every radio is a device record now, which also contains time-boxed association data for who its talked to and been a client of).
> The REST docs are at https://github.com/kismetwireless/kismet/blob/master/docs/dev/webui_rest.md and are pretty complete.
> There's a fairly complete python interface library in git-master under rest_examples/ as well as a bunch of Python code interacting with it.
> With the older kismet-stable code this would be, as you've found, much more difficult - stable organizes data by bssid, and presents data as basically a normalized database - so if you turned on the CLIENT sentence you could get a list of all clients in all bssids, then you'd have to simplify it (because it doesn't understand one client being in multiple networks), then you'd also need to turn on the DEVICE sentence to get all devices, and filter down to unassociated clients.
> There's some example Ruby code for talking the protocol, but it's pretty basic.
> You can see how the old kismet was sort of a product of the time - clients didn't really roam between BSSIDs so the model was "network" not "device"; the new code resolves that by making the model "device" and treating it as a monolithic object.
> If you want to chat about it more, feel free to swing by irc.freenode.net #kismet or the discord server at https://discord.gg/5N4ME9a ... just hang around after you join since I might be idle for a bit.
> > I've definitely been having a good amount of fun learning how to interact with Kismet (though it started with a decent amount of tears and gnashing of teeth - I'm past that, now . . . ) It's quite powerful tool once you figure it out, that's for sure.
> > So, I'm trying to do a bit of presence detection that parses out just the clients and and the unassociated clients (both of them separately) along with a timestamp for each. So far, I've only really interacted with Kismet via netcat, and I'm not sure if I can do this type of parsing and formatting on the fly (though that would be ideal).
> > Basically, I'd like the output to look something like this if the client is connected to an AP:
> > <timestamp> <client_MAC> <AP_MAC>
> > If it is not connected to an AP, then this:
> > <timestamp> <client_MAC> (maybe put something here to indicate no AP)
> > I'm having trouble figuring out how to do this without first dumping the netcat stream to a file and then doing some grep and sed. Any tips?