Thursday, January 5, 2012

Phy-Neutral changes to drones

There's been a slight change in how drones handle things - or rather, changes in how Kismet handles things, which have lead to changes in how drones operate.

Previously, the DLT decode (ie parsing radiotap headers, etc) happened in the drone, and the packet was sent as a decoded kismet radio packet + dot11 mangled chunk. This never sat well with me since the radio parsing code was fairly complex, and it limited what the drone could report.

With preparations for phy-neutral support for pcap files, the DLT decoding has migrated out of the packet capture sources and into the packet chain; the source is responsible for creating a linkframe record in the packet, and then the postcap chain stage triggers to decode it into the appropriate frame type.

This means:

- Phy-agnostic capture sources like pcapfiles no longer make the assumptions it must be a dot11 capture

- Capture sources now solely create a linkframe record, unless they need to do meta-data that isn't encoded in the DLT; directly creating a radio record IS still possible.

- The drone data frame has been DLT-typed for some time now, though always 802.11. Now the same code defaults down to the linkframe layer and sends the raw radiotap, prism2, or whatever (zigbee? btbb?) formatted frame. The only rules are that the DLT type MUST be set equivalently on both ends, and there must be a DLT decoder on the server to handle that DLT type, otherwise the data remains in the linkframe record and is never processed.

- Drones no longer do anything but GPS and packet read; this is more secure, quicker, less code overhead

- Drones CAN still send radio records with a packet, if something comes up w/ a plugin source that reads radio data from outside the packet data stream

This has the nice side effect of being able to play back non-dot11 files if you have the plugins to do so, you can also use PPI on non-dot11 DLTs now as the embedded DLT is carried into the data layer capture record in the PPI decoder.