search

kismetwireless / kismet

Github mirror of official Kismet repository
Other
1.63k stars 309 forks source link

Feature-Request: Expose packet type in packets-db #114

Open omnidepp opened 5 years ago

omnidepp commented 5 years ago

I'm curious whether it would be a great effort to provide some more information in the packets-table of the kismet-db. I would find it very helpful for many analyses to be able to filter on the type of packet kismet has logged, i.e. DATA-frame, probe-request, beacon-frame etc.

kismetwireless commented 5 years ago

Unfortunately that would be extremely difficult to do for all the packet types kismet handles - kismet handles more than wifi, so that data wouldn't be mappable across phy types.

I wouldn't say "no, never" but it's a lot harder than it would seem on the surface; this is the sort of thing other packet-specific tools excel at, however - tshark for example would be an excellent way to filter the packets. Expect some more work towards supporting that in the near-ish future, though the exact form it would take is still being worked on.

On Wed, Feb 20, 2019 at 10:47 AM omnidepp notifications@github.com wrote:

I'm curious whether it would be a great effort to provide some more information in the packets-table of the kismet-db. I would find it very helpful for many analyses to be able to filter on the type of packet kismet has logged, i.e. DATA-frame, probe-request, beacon-frame etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/114, or mute the thread https://github.com/notifications/unsubscribe-auth/AVScY_9fbw8WDphGd13oJsrXUCo4c9Gvks5vPW4rgaJpZM4bFhdx .

omnidepp commented 5 years ago

Thanks for the quick reply. You're right - I have not considered kismet's other use cases apart from wifi.

dragorn commented 5 years ago

I think, possibly, the smoother solution would be to either add kismetdb support directly to wireshark/tshark (I'm working on it, but haven't had the time) or revamp the kismetdb to pcap generator to support stdout output (also something in the works; some of the other tools have it already); that would give an easy path from kismetdb through tshark, which is likely the easiest way to support complex filtering on the data types.

Another option would be to expand into some sort of meta table option and provide a handful of options per packet which could be used by different phys for their own purposes; something like a table that maps phy to field options:

phy_expanded_map phyname option1 text, option2 text, option3 text, option4 text

holding something like

"IEEE802.11", "packet_type", "packet_subtype", "packet_direction", ""

and then expanding the packet rows to include:

... option1 real, option2 real, option3 real, option4 real

It gets a little ugly, but it's about the only way to normalize the packet data cross-phy in a common data table. In that hypothetical example, you'd be able to select where phy = "IEEE802.11" AND option1 = 0 AND option2 = 8 or something, at least, but you'd pretty much HAVE to have the a priori knowledge in the database tool.

On Wed, Feb 20, 2019 at 12:17 PM omnidepp notifications@github.com wrote:

Thanks for the quick reply. You're right - I have not considered kismet's other use cases apart from wifi.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/114#issuecomment-465672594, or mute the thread https://github.com/notifications/unsubscribe-auth/ADIHCI3tGD0CQD83BaprWq7pEjQm97-yks5vPYNAgaJpZM4bFhdx .