Kismet Wireless

Kismet Forums

 

Posted by:Paxton
Subject:Help! Which channel am I on?
Date:08:34:24 25/06/2008

> > I am running Kismet on a number of N810s and it is going like a dream now after a few teething troubles.
>
> 2008-05 with auto-scan disabled? Any other tricks you used?
>
> > I have set it up to scan across a number of channels, which it is clearly doing correctly. My question is, how can I find out which channel it was on when looking at the dump file? The Wireshark wlan.channel filter doesn't seem to work and the only information I seem to have is the channel being used by the beacon frames. If I'm looking at other frames, though, the channel doesn't seem to be available.
>
> Currently this is a problem w/ Kismet - since it coalesces multiple sources (in some configurations) it has to use a common packet header, so it uses just plain 802.11 with no link-type headers.
>
> It would be reasonable to extend the logger to optionally log, say, a radiotap format and convert all the miscellaneous packet headers into one rtap header containing whatever info is available.
>
> The availability of sane channel info, in general, is a bit spotty. If the source supports rtap headers, then Kismet will inherit the channel from the rtap header - which ought to be reliable, since the driver probably knows what channel it's on at this moment. Otherwise, Kismet tries to base the channel info off of whatever the last channel it set was... and this is a bit unreliable, since the driver might not have set the channel yet but returned a complete, or something else moved it, or the firmware still does scanning while in monitor mode which causes it to go to other channels w/out reporting it, etc.
>
> So, short version, I'll see how much hassle it would be to graft a rtap header onto the current Kismet, otherwise it'll definitely go into the newcore rev. I've been holding off hoping the pcap-ng variable header stuff would solidify so that GPS, signal, source, and channel data could all be logged per-frame, but that hasn't really happened, so rtap or PPI might be the compromise (both are readable by wireshark. PPI contains a subset of rtap and the ability to expand, so that may end up being the patch.)
>
> -m



I'm using the http://www.zdez.org/nokismet-0.0.01a.deb package at the moment and have had several tablets running for over 70 hours now. They are just scanning on 1, 6 and 11 with 60s dwell.

The first channel seems to be random, but thereafter it follows the 1,6,11 sequence predictably, so I can use that. I can also look at the channels reported in the beacon frames. So I have a couple of workarounds providing I stick to slow dwell times.

Thanks


Reply to this message