Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Building an all channel USB based Kismet rig. Need advice.
Date:16:59:41 29/04/2008

> I am looking at adding to my rig by purchasing enough USB wireless devices and antennas to monitor all 13-14 channels.
> I know about channel overlap and often see traffic from an adjacent channel while locked to one.

Remember channel 14 is offset.

> The questions are (sorry for so many):
> Whilst locked to a channel will Kismet still dump all packets it sees even if it from a different channel.?

Yes, it won't care what channel something comes from. I'm planning to improve channel support in newcore to leverage the channel from the radiotap header.

> Channel/Device
> 1
> 2 USB1
> 3
> 4 USB2
> 5
> 6 USB3
> 7
> 8 USB4
> 9
> 10 USB5
> 11
> 12 USB6
> 13
> 14 USB7

Channel 14 is equivalently about 3 channels away from channel 13, and if you're in the US isn't used, so I'd probably set it to hop 12/13/14 and concentrate on 1/6/11 as the home channels.

> If i set each radio to hop between 2 adjacent channels would I lose data as the radio changes channel.?

Yes, during a change it will be losing packets since it takes some time for the radio firmware to change.

> On the assumption that only a few of the channels will ever be occupied at the one time is there any way to set the devices to optimally choose their channel configuration. i.e. hop until an AP is seen then lock onto that channel. Essentially make best use of the radios that are available dynamically and in real time.?

I'm working on something like that in newcore, if you want to work on it and send patches that'll get it done sooner.

> And finally this is a bit off topic but I see that many USB manufacturers don't list electrical power requirements. A USB device set to receive only will use less power but has anyone any idea how to accurately determine how many devices can be put on one USB port without hitting power problems?

No idea, but you could dual-port power a hub, like the hacks for portable hard drives.


Reply to this message