Kismet Wireless

Kismet Forums

 

Posted by:dragorn
Subject:Distinguishing between Client & AP
Date:23:02:39 05/04/2011

> > Internally it's differentiated by the tracker using the tods/fromds bits in the 802.11 header.
>
> Thanks Dragorn. Any pointers as to how the new tracker core may affect this just so I can plan ahead for my client?

You can see some of the stubs of it now, via the *COMMON sentence, and in the devicetracker.* files and phy80211.* files.

Currently, networks are presented by a *BSSID and multiple *SSID sentences. The *BSSID contains the SNR, GPS, and so on, as well as the dot11 specific data.

Since there are a number of plugins now which try to expand to non-dot11 PHYs, the common-to-all-phy-layers data is getting pulled into a *COMMON report linked to a MAC addr/phy-id. Phy-specific data (like the dot11 data that wasn't common) will go into its own protocols - probably in this case called *PHYDOT11 or something, so as not to step on *BSSID and break everything. This will also happen for clients - so the dot11 client will turn into it's own phy type, it's common data will be in the *COMMON sentence, and the dot11 specific stuff will be in it's own protocol similar to *CLIENT now. The *INFO sentence is generally getting replaced with the *TRACKINFO sentence since *INFO right now is a bit of a hold-over from old kismet code which doesn't fit into the new model all that well. There'll also be a sentence providing ID#->Name mapping for the PHY protocols.

Internally, devices will be represented like packets are; a common struct with bits of arbitrary data tacked onto it, so plugins will be able to stick their own tracker data, plug their own protocol in, and send it.

The big logical change in your client is you should try to handle as much of *COMMON as you can even when it isn't a dot11 phy - Kismet will be moving towards presenting as much information as it can in a single sortable/filterable widget combining all the PHYs (so dot11, zigbee, bluetooth, dect, whatever, coexisting in one tracking view), with detailed info in the secondary line (the second line that shows up when you highlight it) or in the details window as it is now.

I'd be open to some sort of discussion about setting a standard for phy-detail protocol names and the names of fields in those protocols to try to make an auto-detailer, but I kind of suspect that anything that can be auto-handled will live in *COMMON and so won't be all that detectable - you'll have to add a handler and display for each unknown PHY type.

As for release, since the two tracker cores will be able to co-exist as far as I'm planning, the first Kismet with the new tracker will probably have both enabled with a config file setting to turn off the old one, defaulted to true. The next, or second-next, release will probably disable the old core by default but still have the code. Sometime after that I'll expire the code entirely.

This change will also impact the logfiles - assuming tests go ok, the PPI will be a MUXed file w/ all the different PHYs, we'll be able to do GPS logging with a common file for all the PHYs, and it will allow single-file XML and text.

Ping me on IRC if you want more real-time info, or I'll reply here.


Reply to this message