From: Eric Johanson (ericj_at_cubesearch.com)
Date: 2002-07-27 05:26:51 UTC
I thought I would forward this onto the hostap folks. :)
Kismet is a nifty tool for mapping wireless networks. We got our first (alpha?) patch supportin hostap under kismet.
My question: We hop channels to find APs. (see below). Is there any way to build a hopper that could tell if it's a good time to change? some type of 'busy' flag? or a method to change channels 'at the end of the next packet'?
We are getting lots of these messages when changing the channel rapidly.
wlan0: prism2_rx_80211: len(19878) > MAX(2304)
(len changes, normally less than 32k, but 10k is typical). If I'm reading that right, it's a packet that exceeds the expected frame size for 802.11. Either somebody is doing something VERY nasty to me right now (w/ very good timing when I enable the hopper), or it's being caused by the rapid switching.
Any ideas? I have the latest (as of 20 min ago) cvs version of hostap. We are using monitor mode 3.
TIA,
-Eric
PS. As a totally unrelated asside, I recall seeing a huge thread on jumbo frame support to speed up gig-ethernet cards. With standard packet sizes, interrupt calling was killing the CPU. Would it be possible to use something like jumbo frames to increase speeds on 802.11b? It looks like the headers are HUGE (2304 total for tcpip frame size of 1500? Is that right?).
Hi Andreas,
It looks like it uses 'iwpriv wlan0 monitor 3' to set the promisc flag for what I assume is netlink and prism2 headers. I found some stuff in the hostap archive talking about this 'feature', and uncovered that it's not been released net.
You can get the latest cvs version here:
http://hostap.epitest.fi/cvs.html
At this point, you should be able to run 'iwpriv wlan0 monitor 3'.
On my system, I had an old(er) version of tcpdump. (6-21?-2002, from woody current). I downloaded tcpdump 3.7.1 & libpcap 0.7.1 in order to fix the 'error unknown packet type 119'. I assume 119 is the prism2 headers that monitor mode 3 is passing.
Next step: getting kismet_hopper to really hop.
This is what I get:
Error for wireless request: "Set Frequency" (8B04)
SET failed on device wlan0 ; invalid argument.
I get about a message per second, much less than the 'hopping speed'. It could be only some of the channel requests are timing out or something. I am not using 'international' channels.
Using packet capture type of pcap, using card type 'prism2_hostap', I am able to see ONE access point.
Running tcpdump manually (see versions required, above) with the hopper running, I see traffic from all three of them running in my home.
Very strange. Why would I see all of them from tcpdump, but not kismet? Maybe I need to build kismet with the new libpcap? -devel is using 2002-07-02.
Maybe I need a (even) newer libpcap/tcpdump?
Also, (unrelated?) I get lots of messages about this:
wlan0: prism2_rx_80211: len(19878) > MAX(2304)
This looks like the hostap driver is seeing larger packets than it's expecting; I think this is from the rapid channel changing. I recall seeing a post from Jouni stating that the driver will not block a channel change, so it's up to the hopper to see if there is traffic. I suspect we're seeing the same problem under lucent orinoco_cs drivers (see the archives).
Those messages go away if the hopper is stopped.
Comments?
Thanks,
Eric
On 26 Jul 2002, Andreas Oberritter wrote:
> Hi,
>
> attached is a patch against the latest development snapshot which adds
> support for hostap drivers and fixes some little things in
> kismet_unmonitor.
>
> Regards,
> obi
>
>