I sent the two files (kismet.log and dmesg.log) to you via private message (so I wouldn't be spamming this thread). The issue I am referring to is certainly reproducible (it happens nearly every time I am at the location which has 7 - 10 Cisco wireless access points and a handful of Wi-Fi clients.
Can you please run kismet_server separately and send me the output of it.
I would recommend running the following command:
Code:
kismet_server --no-line-wrap | tee kismet.log
This will start the Kismet server and create the file kismet.log while also letting you view the output of it on terminal.
In a second terminal start Kismet as usual, it should automatically connect to the running server instance.
It would also be good if you can send me your dmesg output. You can put it into a file with e.g.
Code:
dmesg > dmesg.log
Please also keep the other Kismet logfiles like Kismet-*.pcapdump, ... as they might be useful for further debugging, but I don't need them right now.
I found nothing special in your logfiles, can you please send me the pcapdump generated while that Kismet run. (I think best would be to upload it to an oneclick hoster)
The only thing I found in your logfile is that you have installed the btscan plugin, but it shouldn't be active regarding the logfiles. Just to be sure, can you try it again after completely uninstalling btscan?
For all others I want to note that I haven't tested any of the plugins yet.
Does your problem only happen at this location or have it already happened on another place too?
What happens if you run Kismet successfully and go to this special place?
Maybe we should really talk on IRC so I can ask you some more questions.
I apologize about taking so long to respond. Per your instructions, I would like to send you the generated Pcap, but Private Message doesn't allow attachments, please provide your email address via private message to me so I can sedn the file.
The problem of seeing a large number of networks listed on the Kismet status (8 - 15) but seeing none of them listed in the active main screen (only the "AutoGroup") is not unique to a specific location, but it does tend to happen more often in a specific location where I have 8 - 12 Cisco wireless access points available.
To add another wrench into the mix, sometimes in random locations I start up Kismet and I am able to see no wireless networks at all. The generated Pcap shows nothing. In nearly every case a reboot of the device, and/or toggling wlan0 on and off fixes the issue, albeit temporarily.
Please take a look at my private message for the Pcap. These issues came up prior to installing the Btscan plugin.
My monitor mode patch version 2 is now available. It can be downloaded on my blog. Moreover it will be included in the upcoming 2.6.28-maemo35 release of Titan's power kernel.
Changes:
* FIX: capture encrypted packets (thanks to hardkorek for reporting the bug)
* FIX: reported data rate and channel type
Thankyou for your work on this.
As my two day old n900 is back to stock kernel waiting for PR1.2 I haven't tried out your patch or port yet.
But once I'm back on titan's kernels your app will be going straight on.
Below I am posting lxp's response (which was via email), in case other N900 Kismet users are experiencing similar issues:
-----------------------------
I have analysed your pcap file and in combination to your bug
description, I think the problem is due to the driver somehow
misconfigures the wl1251's packet filtering in some special cases. My
patch doesn't touch that part of the driver because my tests showed it
works without modification (for me) so I haven't thought much about it.
I think the bug is triggered by either a special network type or
parameter of a network you connect to before going into monitor mode.
Maybe it is not only caused by a single network but a combination of
different networks if you usually use multiple networks before monitor mode.
It would be good if you could try to determine the network or even
better the parameter itself which causes the problem. At best you would
reboot after every network connect + monitor mode test to get a clean
state for the next try.
I would first suspect ad-hoc networks if you use any because I haven't
tested ad-hoc networking yet.
If you can determine a network which causes the problem, please tell me
the parameters of it:
* network type (infrastructure/ad-hoc),
* encryption type (open/wep/wpa-psk/wpa eap),
* hidden ssid (yes/no) and
* power management (full/half/off)
Maybe you can also suspect a network parameter for triggering the bug.
If you couldn't determine any single network which causes the problem I
think I have to build a debug driver for you, so we can tell for sure
your problem isn't caused by the packet filtering.
In a different note, I understand that once PR 1.2 is installed we N900 Kismet users will have two choices, either wait for the revised version of Titan's power kernel, or apply lxp's updated monitor mode patch directly to the official PR 1.2 release? I understand that Titan's power kernel must be uninstalled prior to PR 1.2 installation.
