Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:bad ideas i guess
Date:23:42:20 20/12/2012

> - stay on the channel if you're seeing a handshake, so you don't ho to another channel and miss some of it while hopping

Right now Kismet doesn't track wpa handshakes, but yes, this is actually on the list for when that happens, though it can be difficult depending on the card and the state it's in.

- option to keep the best

Best what?

> - along with this, option to stay on the channel while hopping if you're seeing a big data burst. with some kind of threshold before you
> start hopping again.

Not unreasonable.

> another idea... if statistically you're seeing little IV's on some channels, start to prefer channels you're seeing alot on ?

Patches welcome; Kismet isn't really directly aimed at cracking wep. In general, I'd consider any network running wep to be vulnerable by default. Autowep and PTW plugins are really just there to prove a point.

However, the PTW plugin could definitely influence the channel hopping. If you or someone else wants to submit a patch.

> - option to not keep big packets ?

Not sure I agree with this one but if someone wants to add a config file option and send a patch I probably wouldn't reject it.

> - option to not pass corrupted packets to pcapdump? (sorry, i'd really like that again:) )

Reasonable, but that whole subsystem is in flux right now so at some point it'll get in.

> - option to decay clients or AP's you haven't seen so they go off the list (is it there already?)

Not unreasonable but probably not something I'll get to in a hurry; patches welcome, just beware of the changes in -git to handle phy-neutral.

> - active probe scanning (and with that, don't pick up beacons) and make sure you only see your own probe requests. this is nice for telling
> what AP's you're in range of connecting to since it was a two-way conversation.

Probably not, but again, if someone really put the work into it to handle dual-card interaction like this I probably wouldn't reject it.

> - option to keep only the first beacon unless it changes then keep another, to reduce log file size?

In general log file size isn't an issue any more so probably not too high on the list, though in theory possible to add log filtering logic to the dot11 phy handler.

If log file size is a real issue b/c of an embedded device, look at drones and storing pcaps on a device w/ real space.

> - to be better that most tools.. maybe discard bad handshakes (aircrack-ng tries to tell you're they're fine to try and crack). if you can tell a handshake went bad.
> since people are always trying to connect to AP's with bad passwords.

This one, absolutely not - Kismet is designed to monitor exactly that sort of weird behavior. Throwing stuff out from the logs is something you can do yourself later if you want (infact tools to filter that might be nice), but for the most part, the logs coming out of Kismet should reflect what happened.

Reply to this message