View Full Version : [Announce] Kismet + Fully functional WLAN monitor mode for the N900
Hi,
Many of you may already have noticed that I have ported Kismet to the N900 with support for internal GPS through liblocation.
Now also a fully functional WLAN monitor mode is available for the N900! You might know the channel 6 problem, it's gone now! :)
Installation instructions can be found here (http://david.gnedt.eu/blog/2010/05/11/kismet-fully-functional-monitor-mode-for-the-n900/).
More infos on my blog http://david.gnedt.eu/.
Monitor mode patch changelog:
Version 2 (included in titan's kernel-power 2.6.28-maemo35 and later)
* FIX: capture encrypted packets (thanks to hardkorek for reporting the bug (http://talk.maemo.org/showthread.php?p=655834#post655834))
* FIX: reported data rate and channel type
Version 1 (included in titan's kernel-power 2.6.28-maemo26 and later)
* Initial version
http://david.gnedt.eu/blog/wp-content/uploads/2010/05/kismet_screenshot.png
Best regards,
David
Well, I would just like to personally thank you for the WL1251 patch.
This is insane!
Cool man!
Could i use your chan 6 problem patch with aircrack since i know aircrack way better than kismet?
Eikido
Thanks a lot for this patch N900 getting more and more a greyhat ;)
@eikido , aircrack works too. (kinda, since injection is not working)
http://h.imagehost.org/0498/screenshot22.png
Could i use your chan 6 problem patch with aircrack since i know aircrack way better than kismet?
It should work with any tool which uses the monitor mode. Nevertheless packet injection will currently not work.
I don't think that aircrack-ng suite is better for wardriving because it isn't directly designed for it. However the aircrack-ng suite is better in other fields ;) but as I already noted packet injection doesn't work, so I think aircrack is currently a little bit useless on the N900 (like kismet before) or did I miss something?
davidxfoo
2010-05-11, 14:45
This is cool! Thanks for the effort.
One question: using your patched driver, can tcpdump or wireshark output the signal strength of received wireless frames?
@lxp;
Would you agree it's a tertiary firmware issue that's stopping live packet injection without being associated to an AP?
One question: using your patched driver, can tcpdump or wireshark output the signal strength of received wireless frames?
I think it should work (if you put the card in monitor mode), but I haven't tested it yet.
Would you agree it's a tertiary firmware issue that's stopping live packet injection without being associated to an AP?
Yes, I am quite sure as some testing showed the same during development of my monitor mode patch. The firmware is a bit crappy at all. It wasn't too easy to get the monitor mode working like it is now. Nevertheless there may be some tricks to also overcome the firmware issues for packet injection, but I can't tell for sure.
davidxfoo
2010-05-11, 17:16
I think it should work (if you put the card in monitor mode), but I haven't tested it yet.
lxp, could you do a quick test and let us know if you can see the signal strength? I remember on my n810 without patch, we can use monitor mode with tcpdump, but without signal strength information.
Thanks a lot.
lxp, could you do a quick test and let us know if you can see the signal strength? I remember on my n810 without patch, we can use monitor mode with tcpdump, but without signal strength information.
Thanks a lot.
I have tested it and it works. The capture contains normal radiotap headers with MAC timestamp, Flags, Data Rate, Channel frequency, Channel type, DBM Antenna Signal, DBM Antenna Noise, Antenna.
Here is what I have done:
stop wlancond
ifconfig wlan0 down
iwconfig wlan0 mode monitor channel 6
ifconfig wlan0 up
tcpdump -i wlan0 -w test.cap
start wlancond
davidxfoo
2010-05-11, 17:53
Thank you so much! I will buy a n900 today.
mail_e36
2010-05-11, 18:01
Thank you very much for this! Ever since seeing the application in the app manager I downloaded right away and have been playing with it. The one thing it was lacking was the N900-specific documentation, which you have now linked to.
Thanks again!
mail_e36
2010-05-11, 18:23
As a follow up. I've read through your documentation, I am wondering what functionality will I loose if I do not install the "Enhanced Linux kernel for power users", and run Kismet with the stock kernel instead? Will I only loose the monitor mode ability, or other functionality as well?
Thank you
I've read through your documentation, I am wondering what functionality will I loose if I do not install the "Enhanced Linux kernel for power users", and run Kismet with the stock kernel instead? Will I only loose the monitor mode ability, or other functionality as well?
The stock kernel generally supports monitor mode, but it only works on channel 6. So I have developed a patch to make monitor mode available on all channels and this patch is included in the "Enhanced Linux kernel for power users" aka titan's power kernel.
Therefore if you run Kismet with the stock kernel, you will only find access points on channel 6.
The interface is difficult to control, and on my device at least, the Esc call does not bring up the menu. Local wireless networks are discovered well and announced through the "INFO:" statment printed to X-Term however there is no other functionality attainable as I cannot reach the menu!
Okay well I figured out the interface problems were caused by a faulty sudo gainroot package; downloading the latest update fixed the problem.
The wlan0 interface is not automatically attaching after kismet is closed.
mail_e36
2010-05-11, 19:52
xlp,
Thank you for the clarification. I have read a little about the "Enhanced Linux kernel for power users" by Titan, but have been reluctant to install it thinking that it might break some stock N900 functionality. Also, I am concerned that the PR 1.2 update would not work with the Titan's Power Kernel. I guess this isn't really a question for you, but hopefully someone on this post can let me know if Titan's Power Kernel can be easily installed and uninstalled without breaking normal functionality.
The stock kernel generally supports monitor mode, but it only works on channel 6. So I have developed a patch to make monitor mode available on all channels and this patch is included in the "Enhanced Linux kernel for power users" aka titan's power kernel.
Therefore if you run Kismet with the stock kernel, you will only find access points on channel 6.
The interface is difficult to control, and on my device at least, the Esc call does not bring up the menu. Local wireless networks are discovered well and announced through the "INFO:" statment printed to X-Term however there is no other functionality attainable as I cannot reach the menu!
I agree with you, but to make the ui better someone has to create a graphical ui for Kismet. I sadly haven't time to do it.
After pressing ESC you have to press at least once a cursor button to show up the menu.
Okay well I figured out the interface problems were caused by a faulty sudo gainroot package; downloading the latest update fixed the problem.
The wlan0 interface is not automatically attaching after kismet is closed.
You shouldn't need sudo gainroot at all, because Kismet also runs as normal user.
I think you have closed Kismet through the X button. That's the only case I haven't tested until now. I will try to fix it.
To circumvent this problem you should close Kismet through the menu or by pressing Ctrl+C.
xlp,
Thank you for the clarification. I have read a little about the "Enhanced Linux kernel for power users" by Titan, but have been reluctant to install it thinking that it might break some stock N900 functionality. Also, I am concerned that the PR 1.2 update would not work with the Titan's Power Kernel. I guess this isn't really a question for you, but hopefully someone on this post can let me know if Titan's Power Kernel can be easily installed and uninstalled without breaking normal functionality.
The new Titan Kernel has its own 'remove kernel' app in the main menu when you install latest version from the repo's this should make it very easy to uninstall.
The kernel will not overclock your n900 unless you create a file with the setting for that in it.
the only thing you will new to worry about is that if you want to recalibrate the touch screen it will crash the calibration app due to a joystick driver that is installed as part of the kernel.
Hope that helps
Cheers
mail_e36
2010-05-12, 15:33
Thanks for the response, it sounds like Titan Kernel is fairly safe to install, assuming I can revert back to stock easily. This is definitely worth it in order to get full Kismet functionality working.
I also assume I would need to revert to stock in preparation for the PR 1.2 upgrade?
You shouldn't have to do anything, apart from reinstall Titan's kernel after the upgrade.
hardkorek
2010-05-12, 19:33
working monitor mode and USB host (which is in progress) was two features that was separating this tablet from perfection.
Now i'm not regreting single euro i paid for n900.
Thank you
hardkorek
2010-05-12, 20:41
Hmm i think there is one problem with the kernel (i have the same issue with ubuntu and atheros chipset. I posted bug report http://bugs.launchpad.net/ubuntu/+source/linux/+bug/530449)
Aircrack-ng can not capture data packet, only frames. You can see it also on screenshoot posted at the begining of this topic. Lot of network and no single data packet - impossible:(
as far as i remember it was possible to capture a data packet on channel 6 in stock kernel, i can't confirm it now cause there is no channel 6 network around.
-------------------update------------
ok i have checked this again using easy debian and aircrack.
I'm able to sniff data at unencrypted networks(didn't saw it before cause i have poor signal to unencrypted networks in my area)
whean i was trying to generate some traffic at my wpa2 network data packet does not increasing. But i can see data packet in wireshark but they are apear as malformed. Data packet don't have a source MAC adress - that is why aircrack doesn't see them (in the same time my debian lenny on pc can see the same packets source MAC adress and aircrack data packet count goes up
screenshot:
http://blackn0de.dontexist.net/~test/shot.png
Aircrack-ng can not capture data packet, only frames. You can see it also on screenshoot posted at the begining of this topic. Lot of network and no single data packet - impossible:(
-------------------update------------
ok i have checked this again using easy debian and aircrack.
I'm able to sniff data at unencrypted networks(didn't saw it before cause i have poor signal to unencrypted networks in my area)
whean i was trying to generate some traffic at my wpa2 network data packet does not increasing. But i can see data packet in wireshark but they are apear as malformed. Data packet don't have a source MAC adress - that is why aircrack doesn't see them (in the same time my debian lenny on pc can see the same packets source MAC adress and aircrack data packet count goes up
Sadly you are right, it is impossible to capture encrypted data packets. I suspect the hardware decryption of the wl1251 chip to break encrypted packets. I will try to fix it, but at this point I can't promise anything.
My recent tests showed that this doesn't break WPA handshake capturing as the handshake itself only consists of unencrypted 802.11 data packets.
Therefore this bug only affects WEP cracking and general data sniffing whereas Wardriving and WPA cracking isn't affected.
as far as i remember it was possible to capture a data packet on channel 6 in stock kernel, i can't confirm it now cause there is no channel 6 network around.
I have checked some old capture files made with Kismet and the stock kernel without patched driver. It shows exactly the same problem.
mail_e36
2010-05-13, 15:16
lxp,
Thank you for your quick responses on previous posts. Can you please tell me where the "kismet.conf" file is your Kismet N900 version? I understand usually it's in "/etc/kimset/kismet.conf" on the desktop version of Kismet.
The reason I would like to get access to kismet.conf is disable the AutoGroup settings which are normally set to:
# Do we autogroup data-only networks?
autogroup_data=true
# Do we autogroup adhoc networks?
autogroup_adhoc=true
I want to do this because sometimes Kismet on the N900 shows that it can see 5 to 10 networks, but provides no real detailed entries other than "AutoGroup" (no SSIDs, but does show apparent MAC address of clients).
Please let the group know, thank you again.
AFAIK, it says right in his blog post. In any fashion, it's /opt/kismet/etc/kismet.conf
Can you please tell me where the "kismet.conf" file is your Kismet N900 version? I understand usually it's in "/etc/kimset/kismet.conf" on the desktop version of Kismet.
You can find it on my blog. Here is the important part for your question:
Logfiles are located in /home/user/MyDocs (path can be configured in the Kismet server configuration located in /opt/kismet/etc/kismet.conf)
UI/Client configuration files are located in /home/user/.kismet or /root/.kismet (if running as root)
Server configuration files are located in /opt/kismet/etc
Update: Thanks hawaii, you were a bit faster ;)
mail_e36
2010-05-13, 17:07
Unfortunately I was not able to locate the "autogroup_data" field in the UI/Client configuration file which is located in /home/user/.kismet. (or any other files in that directory). I also wasn't able to locate the "autogroup_data" field in the kismet.conf file.
Can anyone point me in the right direction? The reason I would like to get access to find the autogroup_data field is disable the AutoGroup settings which are normally set to:
# Do we autogroup data-only networks?
autogroup_data=true
# Do we autogroup adhoc networks?
autogroup_adhoc=true
hardkorek
2010-05-13, 22:15
Sadly you are right, it is impossible to capture encrypted data packets. I suspect the hardware decryption of the wl1251 chip to break encrypted packets. I will try to fix it, but at this point I can't promise anything.
I hope you will find a way to fix it. Anyway it feels good to have in pocket device capable to crack WPA;)
Unfortunately I was not able to locate the "autogroup_data" field in the UI/Client configuration file which is located in /home/user/.kismet. (or any other files in that directory). I also wasn't able to locate the "autogroup_data" field in the kismet.conf file.
Can anyone point me in the right direction?
I quickly did a grep on the Kismet code and couldn't find anything relevant, so it currently might be impossible in Kismet newcore.
I have forwarded your question to dragorn (the Kismet developer). As soon as I get an answer I will update my post.
UPDATE: Also dragorn said it is currently not possible and it looks like he is currently not planing to implement it in the near future, as he would welcome patches. I am sorry but I also won't implement it because I have enough on my todo list with higher priority.
mail_e36
2010-05-14, 13:51
lxp,
Thank you very much, I look forward to the response.
I quickly did a grep on the Kismet code and couldn't find anything relevant, so it currently might be impossible in Kismet newcore.
I have forwarded your question to dragorn (the Kismet developer). As soon as I get an answer I will update my post.
mail_e36
2010-05-17, 00:07
I should add that I did install Titan's power kernel to work with monitor mode, and so far I've seen no issues with the power kernel.
However, at times I have noticed that when I run Kismet I am unable to pick up any wireless networks... running 'ifconfig' shows wlan0 in promiscuous mode, but doesn't show any traffic flow. After closing Kismet I am unable to connect to any wireless networks also. I'm guessing this is an issue with the driver, I would say that 70% of the time Kismet works well.
kingoddball
2010-05-17, 01:35
How can I use Kismet to crack my WEP connection key?
It is MY OWN network that I want to use to test, I have just had trouble finding a good simple (novice friendly) guide that works on the N900.
Can anyone help?
However, at times I have noticed that when I run Kismet I am unable to pick up any wireless networks... running 'ifconfig' shows wlan0 in promiscuous mode, but doesn't show any traffic flow. After closing Kismet I am unable to connect to any wireless networks also. I'm guessing this is an issue with the driver, I would say that 70% of the time Kismet works well.
It is intended that you couldn't connect to any wireless network while running Kismet because you couldn't put your wifi card into two different modes like monitor and managed at the same time (at least with the current wl1251 driver).
How did you close Kismet?
As I already have mentioned in this thread it wouldn't work if you close Kismet through the X button. Try to close it by Ctrl+C or even better through the menu.
How can I use Kismet to crack my WEP connection key?
It is MY OWN network that I want to use to test, I have just had trouble finding a good simple (novice friendly) guide that works on the N900.
1. You wouldn't want to do WEP cracking until packet injection is working for the wl1251 chip.
2. If you have troubles with YOUR WEP network, press the reset button on the ap and configure it for WPA ;)
3. If you really want to do WEP cracking, go to a different platform e.g. a notebook with a decent wifi chip or external wifi card.
4. If you still want to go for WEP cracking on the N900 yet, use a software which is designed for it like aircrack-ng. But remember 1., so either you have a high traffic WEP network or you will have to capture pakets for a very very long time.
5. If you are really crazy you can also use Kismet for WEP cracking on the N900. There is an untested plugin out called kismet-ptw. I wouldn't recommend using this plugin, especially on the N900 as it will cause a huge system load and will drain your battery.
mail_e36
2010-05-17, 15:50
[QUOTE=lxp;662324]It is intended that you couldn't connect to any wireless network while running Kismet because you couldn't put your wifi card into two different modes like monitor and managed at the same time (at least with the current wl1251 driver).
lxp,
I understand that I should not be able to connect to any wireless networks while running Kismet, what I meant is that at times Kismet cannot see any wireless networks at all while running, or it groups all networks it sees into "AutoGroup". A reboot of the N900 usually fixes this strange. issue.
I understand that I should not be able to connect to any wireless networks while running Kismet, what I meant is that at times Kismet cannot see any wireless networks at all while running, or it groups all networks it sees into "AutoGroup". A reboot of the N900 usually fixes this strange. issue.
How do you run Kismet? As user or root? Do you run the Kismet server through the client or have you started it manually?
If you want you can contact me through IRC so we may find the cause of your problem faster. (server: irc.freenode.net channel: #kismet nick: lxp)
mail_e36
2010-05-18, 17:57
lxp,
Please see the screenshot for a visual on the issue I am referring to. Notice Kismet says there are 13 networks, yet I only get two AutoGroup entries. I know for a fact that there are at least 7 different Cisco wireless networks (at the place where I took the screenshot). There are also numerous wireless clients around. It may be important to note that when the screenshot was taken I was not associated with any wireless access points (I rebooted and then took the screenshot). I was running Kismet as root. If I enable the Client List within the Kismet UI I am able to see the MAC addresses and Manufacturer information for various wireless clients around my area. I run the Kismet server through the client UI via the normal Kismet UI start-up process.
Please let me know if you can shine some light on this.
mail_e36
2010-05-18, 18:11
...and closing Kismet via the UI produces the below message. I'm not sure if this is normal.
mail_e36,
Can you please run kismet_server separately and send me the output of it.
I would recommend running the following command:
kismet_server --no-line-wrap | tee kismet.logThis 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.
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.
...and closing Kismet via the UI produces the below message. I'm not sure if this is normal.
It is normal at least for now.
Did anyone tested the patch from this website http://david.gnedt.eu/blog/2010/05/11/kismet-fully-functional-monitor-mode-for-the-n900/ ? It is supposed to give the ability of putting the device in monitor mode......I couldn't get it to work...
Did you EVEN read the thread? The author of that site, created this thread with a link to that post and explained it all in the first freaking post.
What is wrong with 90% of the people here?
mail_e36
2010-05-19, 17:30
lxp,
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.
Thank you
mail_e36,
Can you please run kismet_server separately and send me the output of it.
I would recommend running the following command:
kismet_server --no-line-wrap | tee kismet.logThis 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.
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.
It is normal at least for now.
mail_e36,
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.
mail_e36
2010-05-24, 17:26
Hello lxp,
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.
Thank you again.
My monitor mode patch version 2 is now available. It can be downloaded on my blog (http://david.gnedt.eu/blog/2010/05/25/updated-monitor-mode-patch-for-n900/). 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 (http://talk.maemo.org/showthread.php?p=655834#post655834))
* FIX: reported data rate and channel type
Awesome. Thanks for your work, lxp. It's greatly appreciated.
stableHand
2010-05-25, 13:42
lxp
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.
mail_e36
2010-05-25, 17:18
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.
mail_e36
2010-05-25, 17:21
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.
Thanks
titan's power35 and up, incorporate the new patch.
mail_e36
2010-05-25, 19:48
I do understand that Titan's Power35 and up will incorporate the new patch, but my question is:
If I am currently running Titan's Power Kernel, do I have to downgrade back to the Nokia kernel to upgrade from PR 1.1 to PR 1.2?
After I upgrade to PR 1.2 can I immediately upgrade to the latest Titan Power Kernel, or do I have to wait for Titan to incorporate PR 1.2 into his kernel?
I realize this is not the ideal audience for this question, but I think the N900 Kismet users are more knowledgeable on these things than the regular N900 users :)
If I am currently running Titan's Power Kernel, do I have to downgrade back to the Nokia kernel to upgrade from PR 1.1 to PR 1.2?
Yes, it is recommended to uninstall the titan kernel before upgrading to PR 1.2. See http://wiki.maemo.org/Kernel_Power#Upgrading_to_a_new_PR
After I upgrade to PR 1.2 can I immediately upgrade to the latest Titan Power Kernel, or do I have to wait for Titan to incorporate PR 1.2 into his kernel?
All current versions in extras, extras-testing and extras-devel should be compatible with PR1.2. Titan has incorporated the latest minor PR1.2 updates in version 35.
(Source: http://talk.maemo.org/showthread.php?p=676177)
Yes, it is recommended to uninstall the titan kernel before upgrading to PR 1.2. See http://wiki.maemo.org/Kernel_Power#Upgrading_to_a_new_PR
update: you don't to uninstall before upgrading, just reinstall after the upgrade.
mail_e36
2010-05-27, 14:01
I have delayed my response since I wanted to test the N900 Kismet application with PR 1.2.
I installed PR 1.2 after doing a complete re-flashof the device, after that I installed the latest Power Kernel from Titan. I have done several reboots and so far Kismet seems to be working properly, I don't have the problem I had before with everything getting autogrouped. I will continue to test this for a few days to see the outcome before having you go through any more work by writing a debug driver or anything else.
The only issue I've encountered so far is after I properly exit Kismet I get a message saying "Kismet is Shutting Down" on xterm but it never drop me back to the prompt unless I press Control C.
Thanks,
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.
I have done several reboots and so far Kismet seems to be working properly, I don't have the problem I had before with everything getting autogrouped.
I like it when bugs resolve themselves. It's much less work :)
If anyone else experiences similar problems with PR1.2 and a recent power kernel, please tell me.
The only issue I've encountered so far is after I properly exit Kismet I get a message saying "Kismet is Shutting Down" on xterm but it never drop me back to the prompt unless I press Control C.
I already know that problem, but I haven't found the cause yet. I first didn't even noticed the bug as I am always using Ctrl+C directly in the client to exit Kismet. As far as I know this doesn't produce any corrupted logs or something, so I would also recommend it as a workaround until the other way works again.
Help me pleaseeee,
The file "/opt/kismet/etc/kismet.conf" doesn`t exist for me. :(
The file "/opt/kismet/etc/kismet.conf" doesn`t exist for me. :(
If you used the stock file manager to search for the file, you couldn't even find it because the stock file manager doesn't show the real root fs. You have to use the terminal or a SSH/SFTP connection to your N900, so you have access to the real root fs.
If you are really sure that the config file doesn't exist, I would recommend to try uninstalling and reinstalling the kismet package through the program manager.
But remember if you can run the kismet server and it doesn't complain about a missing kismet.conf, then it does exist and you only couldn't find it.
Thanks for the reply, but I installed and reinstalled and not working.
Kismet.conf file does not exist.
http://img715.imageshack.us/img715/2909/screenshot58.png
And the server doesn`t work too.
http://img63.imageshack.us/img63/994/screenshot65.png
I have PR1.2 and the latest Titan`s kernel 2.6.28.10power37.
:(
Thank you for all.
A friend sent me the file "kismet.conf" and now it works.
Thank you for all.
A friend sent me the file "kismet.conf" and now it works.
Good that it's working for you now.
If someone else has the same problem, please tell me. Maybe there is a problem with PR 1.2 and the Kismet package.
mail_e36
2010-06-01, 14:26
lxp,
As an update to my last post, since flashing my N900 and upgrading to PR 1.2 I no longer experience the the 'Autogrouping everything' problem.
The problem was likely linked to my highly modified instance of PR 1.1.
On a different note, what is your opinion on these Kismet plugins which have recently popped up for the N900 Kismet application? Have you tried any of them, have you had any luck with them?
Thanks again
I have delayed my response since I wanted to test the N900 Kismet application with PR 1.2.
I installed PR 1.2 after doing a complete re-flashof the device, after that I installed the latest Power Kernel from Titan. I have done several reboots and so far Kismet seems to be working properly, I don't have the problem I had before with everything getting autogrouped. I will continue to test this for a few days to see the outcome before having you go through any more work by writing a debug driver or anything else.
The only issue I've encountered so far is after I properly exit Kismet I get a message saying "Kismet is Shutting Down" on xterm but it never drop me back to the prompt unless I press Control C.
Thanks,
On a different note, what is your opinion on these Kismet plugins which have recently popped up for the N900 Kismet application? Have you tried any of them, have you had any luck with them?
I haven't tested any of the plugins because non of them are useful for myself. The following is only my opinion about the usability of the plugins.
kismet-plugin-autowep (http://maemo.org/packages/view/kismet-plugin-autowep/) - Calculate WEP key for one specific access point type
Useful if you have a supported ap in range. See http://xkyle.com/2009/03/03/verizon-fios-wireless-key-calculator/
kismet-plugin-btscan (http://maemo.org/packages/view/kismet-plugin-btscan/) - Active Bluetooth scanning
I am pretty sure btscan will badly influence the wlan scanning results as it does ACTIVE bluetooth scanning.
kismet-plugin-dot15d4 (http://maemo.org/packages/view/kismet-plugin-dot15d4/) - Support for 802.15.4 low-power network sensors, ...
Useless without special scanning hardware. Moreover the plugin seems to be incomplete.
kismet-plugin-ptw (http://maemo.org/packages/view/kismet-plugin-ptw/) - Tries to brouteforce the WEP key for networks in range (using aircrack-ng code)
I think that plugin will cause enormous battery drain because of the high cpu usage.
kismet-plugin-spectools (http://maemo.org/packages/view/kismet-plugin-spectools/) - Displays wireless spectrum discovered by spectrum analysers like the Wi-Spy (tm Metageek)
Useless without special scanning hardware.
Just wanted to chime in here, for some reason offline mode is being enabled when kismet is invoked. I'm not sure if it's the server or the client.
This shouldn't happen.
Just wanted to chime in here, for some reason offline mode is being enabled when kismet is invoked. I'm not sure if it's the server or the client.
This shouldn't happen.
This is part of expected behaviour, exactly speaking kismet_server should put wlancond in offline mode and the rest of the system shouldn't be affected. This should result in WLAN being unavailable while running kismet_server but GSM/UMTS should work as normal.
That hack is needed because wlancond interferes with monitor mode. Completely stopping and starting wlancond is error-prone, so I have decided to use the offline mode way.
The only problem I am aware of until now is if you exit Kismet through the X button it wouldn't restore the wlancond status. You should exit it using Ctrl+C as a workaround of that problem.
I also expect monitor mode will break if you manually change online/offline mode while using Kismet.
GSM is dropped out for me. I'll do some more testing and report back
hi
to do a handsake with n900 asuming thet you have clients on the network you need injetion?
i capture a .cap with one handshake but i got not passfrase in dictionari ( i use password.lst feom aircrack and password.lst from jack the reapper)
i do somting wrong or is just becose injection is not working with n900?
Live injection without association does NOT work with the WL1251. Seems to be an issue with tertiary firmware AND drivers. Wait a while.
mail_e36
2010-06-11, 14:07
Hello everyone,
It appears I spoke too soon in my previous posting when I said there is no problem under PR 1.2.
Indeed all the same problems I had with my customized PR 1.1 have now come back with PR 1.2 (I did a completely fresh flash of everything on my N900, not an upgrade from PR 1.1), including the problem which "AutoGroups" everything came back.
Additionally, at times when I start up Kismet it cannot even bind to the wireless interface, with the console reading "capture source 'wlan0' doesn't appear to use the set_prismhdr i control". Selecting "Close Console Window" persistently shows zero visible networks in areas of high network concentrations.
Sometimes a reboot resolves the problem, more often a reboot does not resolve the problem.
I am running Power Kernel 2.6.28.10power37, dated May 26th 2010. Do we suspect this to be a driver issue?
Has any experience similar issues?
lxp,
As an update to my last post, since flashing my N900 and upgrading to PR 1.2 I no longer experience the the 'Autogrouping everything' problem.
The problem was likely linked to my highly modified instance of PR 1.1.
On a different note, what is your opinion on these Kismet plugins which have recently popped up for the N900 Kismet application? Have you tried any of them, have you had any luck with them?
Thanks again
Looks promising, but is it safe to use this app on Titans V37 on FW 1.2 already? Thanks in advance for a reply.
mail_e36
2010-06-11, 15:20
For more information, I have recently updated to the newest Power Kernel from the previous version, it is very possible that the problem with Kismet started showing up after upgrading to the latest Power Kernel (Power Kernel 2.6.28.10power37).
Here is the basic timeline (if it is of any help:) I installed PR 1.2 the day it was released, installed the newest available Power Kernel, and things were running smoothly, Kismet was working well. About a week after PR 1.2 is released Titan released his new version of the Power Kernel, I upgraded to it, and didn't check Kismet for a while. I finally had some time to try Kismet and I started experiencing the previously stated problems with Kismet.
This would lead me to suspect the new Power Kernel causing the issue to come back, but this is more of a hypothesis than a fact.
Is anyone running the latest Power Kernel 2.6.28.10power37 with the latest Kismet, do you experience problems?
Thanks
Hello everyone,
It appears I spoke too soon in my previous posting when I said there is no problem under PR 1.2.
Indeed all the same problems I had with my customized PR 1.1 have now come back with PR 1.2 (I did a completely fresh flash of everything on my N900, not an upgrade from PR 1.1), including the problem which "AutoGroups" everything came back.
Additionally, at times when I start up Kismet it cannot even bind to the wireless interface, with the console reading "capture source 'wlan0' doesn't appear to use the set_prismhdr i control". Selecting "Close Console Window" persistently shows zero visible networks in areas of high network concentrations.
Sometimes a reboot resolves the problem, more often a reboot does not resolve the problem.
I am running Power Kernel 2.6.28.10power37, dated May 26th 2010. Do we suspect this to be a driver issue?
Has any experience similar issues?
hi
kismet cand capture handsake data pack?
Kismet will capture any and all traffic "on the wire". Data, beacons, management frames, including wpa handshakes if they take place.
thank you!
i try to capture some data but no luck with handshakes. i will try some more.
Creamy Goodness
2010-06-11, 19:20
Looks promising, but is it safe to use this app on Titans V37 on FW 1.2 already? Thanks in advance for a reply.
Is anyone running the latest Power Kernel 2.6.28.10power37 with the latest Kismet, do you experience problems?
Sometimes it doesn't work on the first try, but I've never had to restart the device. ctrl-c and then launching again has always worked.
I'll try it right now... and it worked, first try.
Maybe you should try returning to stock frequencies/voltages and see if that helps.
no problem with power kernel 2.6.28.10power37 so far
Hello
I run 2.6.28.10power37 kernel overklocked ideal to 700 MHz.
Also have PR1.2 and latest kismet.
I have to run as root, when I do I see many networks and packets coming on them.
Diff between you and me I have never ran an older power kernel and never reflashed.
tuxsavvy
2010-06-14, 00:22
Ok as requested by lxp, I hereby report my findings on kismet with almost latest stuff.
PR1.2 firmware: flashed without using OTA method. eMMC remains stock.
kernel: 2.6.28.10power37. No other kernel hack patches added on.
wireless power management: off (disabled completely via wlancond with settings from one AP profile).
The issue seems to be with bluetooth co-existance. I originally had my bluetooth turned on but in hidden mode and the results from both kismet and airodump-ng only showed probes (along with autogroup probe under kismet) but no APs except when I physically raised the height of the n900 I was only able to pick up one or two (along with physically rotating n900). However whilst constantly on the move I was not able to pick up any APs only probes.
The issue was later solved by turning off bluetooth completely which resulted in perfectly working kismet along with airodump-ng.
Thanks again to lxp (lxp1 on #kismet at irc.freenode.net) for the help :)
(edit) It was interesting to note however, during bluetooth module being turned on and set to hidden mode, the wireless module device being in managed mode (not monitor mode), it was able to pick up far more APs with active probing. (/edit)
mail_e36
2010-06-14, 15:19
tuxsavvy,
It seems like you have solved my mystery! Indeed when I test Kismet with Bluetooth DISABLED it seems to run perfectly, but when Bluetooth is on (even in "hidden mode") I only get probes.
I certainly agree the problem is with Bluetooth and Kismet co-existence. While this would be great to fix, we can certainly live with turning off Bluetooth before running Kismet. Lxp should document this, though.
Thanks!
Ok as requested by lxp, I hereby report my findings on kismet with almost latest stuff.
PR1.2 firmware: flashed without using OTA method. eMMC remains stock.
kernel: 2.6.28.10power37. No other kernel hack patches added on.
wireless power management: off (disabled completely via wlancond with settings from one AP profile).
The issue seems to be with bluetooth co-existance. I originally had my bluetooth turned on but in hidden mode and the results from both kismet and airodump-ng only showed probes (along with autogroup probe under kismet) but no APs except when I physically raised the height of the n900 I was only able to pick up one or two (along with physically rotating n900). However whilst constantly on the move I was not able to pick up any APs only probes.
The issue was later solved by turning off bluetooth completely which resulted in perfectly working kismet along with airodump-ng.
Thanks again to lxp (lxp1 on #kismet at irc.freenode.net) for the help :)
(edit) It was interesting to note however, during bluetooth module being turned on and set to hidden mode, the wireless module device being in managed mode (not monitor mode), it was able to pick up far more APs with active probing. (/edit)
mail_e36
2010-06-16, 20:07
Lxp,
If you find a few minutes free you may want to update your website to reflect the below information. Knowing this would have saved me tons of time :)
tuxsavvy,
It seems like you have solved my mystery! Indeed when I test Kismet with Bluetooth DISABLED it seems to run perfectly, but when Bluetooth is on (even in "hidden mode") I only get probes.
I certainly agree the problem is with Bluetooth and Kismet co-existence. While this would be great to fix, we can certainly live with turning off Bluetooth before running Kismet. Lxp should document this, though.
Thanks!
Lxp,
If you find a few minutes free you may want to update your website to reflect the below information. Knowing this would have saved me tons of time :)
I have documented it now in my blog.
A big thanks to tuxsavvy who greatly helped solving this problem.
mail_e36
2010-06-17, 13:59
Thanks! You were off the grid for a few days (you usually respond right away on this thread), some of us may have thought something happened to you lol
Thanks! You were off the grid for a few days (you usually respond right away on this thread), some of us may have thought something happened to you lol
I am all right. I am currently just a bit busy.
Does anybody else still experience GSM drop-out / Offline mode activation WITHOUT automatic re-enabling?
I can set it back to "Normal" mode easily though, so not a real huge issue.
I've also given the PTW plugin a whirl and it works as described. Ran it against a network for about 12 minutes and it automagically determined the 104 bit key after around 80,000 IV's
hi
how did you load the autowep plugin in kismet ptw?
AutoWEP is a separate plugin from PTW.
David has also packaged the autowep and PTW plugins, they are sitting in the repository. Once installed, they are loaded by the server and work completely transparently.
Any more information you need, you can find at kismetwireless.net or the man pages.
hi!
thx, i will try home kismet ptw on my own network to see.
WillianWives
2010-07-13, 05:12
I installed it, but I made a huge mistake. I hitted yes when the app asked me about the font color. How can I change it now? I tryed to reinstall kismet, but it didnt worked...
:confused:
never used this before but most apps store their settings in an invisible folder in the home directory with the same name as the app (e.g. .kismet).
you could try uninstalling, then wiping that folder, and reinstalling.
As already stated, /opt/kismet/etc is the location.
That is all.
I installed it, but I made a huge mistake. I hitted yes when the app asked me about the font color. How can I change it now?
The easiest way would be to remove the kismet_ui.conf.
The UI/Client configuration files are located in /home/user/.kismet or /root/.kismet (if running as root)
Afterwards you only need to run kismet and you will get asked again.
You don't need to reinstall it.
mail_e36
2010-07-13, 16:33
Good info, Hawaii. Here is the actual link:
http://maemo.org/packages/view/kismet-plugin-ptw/
"Wireless 802.11b monitoring tool - Plugin PTW
Kismet is a 802.11b wireless network sniffer. It is capable of sniffing using almost any supported wireless card using the Airo, HostAP, Wlan-NG, and Orinoco (with a kernel patch) drivers.
Kismet is a command-line only program and so should be used inside X Terminal.
WARNING: This plugin can cause heavy load.
Kismet-PTW is a Kismet plugin which performs the Aircrack-NG PTW attack against data captured by Kismet.
The Aircrack-NG PTW attack exploits flaws in WEP to expose the original keystream. Because the PTW attack needs relatively few packets (50,000 to 100,000) and is relatively CPU cheap, it makes sense to include this as an automatic feature.
While Aircrack-NG can use injection to accelerate the rate at which packets are generated, increasing the chances of deriving the key, the Kismet-PTW version is 100% passive. Kismet will NOT inject packets or actively attack a network, with this plugin it will simply examine the data it has already recorded.
The code for the PTW attack is directly extracted from Aircrack-NG, this plugin simply wraps the Aircrack-NG library into a form Kismet can use directly. For complete info about the PTW attack or Aircrack, see the Aircrack-NG project at: http://www.aircrack-ng.org"
AutoWEP is a separate plugin from PTW.
David has also packaged the autowep and PTW plugins, they are sitting in the repository. Once installed, they are loaded by the server and work completely transparently.
Any more information you need, you can find at kismetwireless.net or the man pages.
I've adjusted the PTW plugin to require more packets before attempting to retrieve a key, this should reduce the load once you hit over 5k dumps. I've also chopped down client text updates to remove console scrolling of logs and cluttering.
FYI, a new release of Kismet was pushed out today. Hope to get it compiled and working soon. David will probably push to a repo before me, I tend to keep all my tools to myself :D
mail_e36
2010-07-13, 21:39
Hawaii,
If David (lxp) does not get it compiled and pushed to the repo it would be great if you would :)
I've enjoyed your blog, especially the part about MetaSploit on the N900, so please don't keep the N900 tools to yourself :)
mail_e36
2010-07-13, 22:21
Has anyone received the below error when trying to start the PTW plugin within Kismet?
"No Plugins Found"
"Server plugins cannot currently be loaded/unloaded frim the UI"
Please see attached image. Can anyone point me in the right direction to get this running?
Thank you
I've adjusted the PTW plugin to require more packets before attempting to retrieve a key, this should reduce the load once you hit over 5k dumps. I've also chopped down client text updates to remove console scrolling of logs and cluttering.
FYI, a new release of Kismet was pushed out today. Hope to get it compiled and working soon. David will probably push to a repo before me, I tend to keep all my tools to myself :D
PTW plugin is attached at the server level, not client. The plugin is loaded in that screenshot, as indicative under the "server plugins" section right below the message you're reading.
Also, as it states, you can't unload a server plugin while it's running. If you want to temporarily disable it, rename the link/shared object in /opt/kismet/lib/kismet.
Thanks for the words regarding my site. I don't always have time to push packages to the repos, especially due to autobuilder, bleh. I'm off for the N97MiniTour with the Nokia Canada peeps soon, so I'll try and get something up; even if it's just a binary package attached to a post here.
I'LL DO IT FOR YOU BECAUSE YOU'RE SO NICE.
can anyone upload the kismet configuration files in /home/opt/kismet/etc ? Really appreciate it. Thanks!
tuxsavvy
2010-09-19, 11:04
can anyone upload the kismet configuration files in /home/opt/kismet/etc ? Really appreciate it. Thanks!
kismet.conf:
# Kismet config file
# Most of the "static" configs have been moved to here -- the command line
# config was getting way too crowded and cryptic. We want functionality,
# not continually reading --help!
# Version of Kismet config
version=2009-newcore
# Name of server (Purely for organizational purposes)
servername=Kismet_2009
# Prefix of where we log (as used in the logtemplate later)
logprefix=/home/user/MyDocs
# Do we allow plugins to be used? This will load plugins from the system
# and user plugin directiories when set to true (See the README for the default
# plugin locations).
allowplugins=true
# See the README for full information on the new source format
# ncsource=interface:options
# for example:
# ncsource=wlan0
# ncsource=wifi0:type=madwifi
# ncsource=wlan0:name=intel,hop=false,channel=11
ncsource=wlan0
# Comma-separated list of sources to enable. This is only needed if you defined
# multiple sources and only want to enable some of them. By default, all defined
# sources are enabled.
# For example, if sources with name=prismsource and name=ciscosource are defined,
# and you only want to enable those two:
# enablesources=prismsource,ciscosource
# Control which channels we like to spend more time on. By default, the list
# of channels is pulled from the driver automatically. By setting preferred channels,
# if they are present in the channel list, they'll be set with a timing delay so that
# more time is spent on them. Since 1, 6, 11 are the common default channels, it makes
# sense to spend more time monitoring them.
# For finer control, see further down in the config for the channellist= directives.
preferredchannels=1,6,11
# How many channels per second do we hop? (1-10)
channelvelocity=3
# By setting the dwell time for channel hopping we override the channelvelocity
# setting above and dwell on each channel for the given number of seconds.
#channeldwell=10
# Channels are defined as:
# channellist=name:ch1,ch2,ch3
# or
# channellist=name:range-start-end-width-offset,ch,range,ch,...
#
# Channels may be a numeric channel or a frequency
#
# Channels may specify an additional wait period. For common default channels,
# an additional wait period can be useful. Wait periods delay for that number
# of times per second - so a configuration hopping 10 times per second with a
# channel of 6:3 would delay 3/10ths of a second on channel 6.
#
# Channel lists may have up to 256 channels and ranges (combined). For power
# users scanning more than 256 channels with a single card, ranges must be used.
#
# Ranges are meant for "power users" who wish to define a very large number of
# channels. A range may specify channels or frequencies, and will automatically
# sort themselves to cover channels in a non-overlapping fashion. An example
# range for the normal 802.11b/g spectrum would be:
#
# range-1-11-3-1
#
# which indicates starting at 1, ending at 11, a channel width of 3 channels,
# incrementing by one. A frequency based definition would be:
#
# range-2412-2462-22-5
#
# since 11g channels are 22 mhz wide and 5 mhz apart.
#
# Ranges have the flaw that they cannot be shared between sources in a non-overlapping
# way, so multiple sources using the same range may hop in lockstep with each other
# and duplicate the coverage.
#
# channellist=demo:1:3,6:3,11:3,range-5000-6000-20-10
# Default channel lists
# These channel lists MUST BE PRESENT for Kismet to work properly. While it is
# possible to change these, it is not recommended. These are used when the supported
# channel list can not be found for the source; to force using these instead of
# the detected supported channels, override with channellist= in the source defintion
#
# IN GENERAL, if you think you want to modify these, what you REALLY want to do is
# copy them and use channellist= in the packet source.
channellist=IEEE80211b:1:3,6:3,11:3,2,7,3,8,4,9,5, 10
channellist=IEEE80211a:36,40,44,48,52,56,60,64,149 ,153,157,161,165
channellist=IEEE80211ab:1:3,6:3,11:3,2,7,3,8,4,9,5 ,10,36,40,44,48,52,56,60,64,149,153,157,161,165
# Client/server listen config
listen=tcp://127.0.0.1:2501
# People allowed to connect, comma seperated IP addresses or network/mask
# blocks. Netmasks can be expressed as dotted quad (/255.255.255.0) or as
# numbers (/24)
allowedhosts=127.0.0.1
# Maximum number of concurrent GUI's
maxclients=5
# Maximum backlog before we start throwing out or killing clients. The
# bigger this number, the more memory and the more power it will use.
maxbacklog=5000
# Server + Drone config options. To have a Kismet server export live packets
# as if it were a drone, uncomment these.
# dronelisten=tcp://127.0.0.1:3501
# droneallowedhosts=127.0.0.1
# dronemaxclients=5
# droneringlen=65535
# OUI file, expected format 00:11:22<tab>manufname
# IEEE OUI file used to look up manufacturer info. We default to the
# wireshark one since most people have that.
ouifile=/opt/kismet/etc/manuf
ouifile=/etc/manuf
ouifile=/usr/share/wireshark/wireshark/manuf
ouifile=/usr/share/wireshark/manuf
# Do we have a GPS?
gps=true
# Do we use a locally serial attached GPS, or use a gpsd server?
# (Pick only one)
gpstype=liblocation
# gpstype=serial
# What serial device do we look for the GPS on?
gpsdevice=/dev/rfcomm0
# Host:port that GPSD is running on. This can be localhost OR remote!
gpshost=localhost:2947
# Do we lock the mode? This overrides coordinates of lock "0", which will
# generate some bad information until you get a GPS lock, but it will
# fix problems with GPS units with broken NMEA that report lock 0
gpsmodelock=false
# Do we try to reconnect if we lose our link to the GPS, or do we just
# let it die and be disabled?
gpsreconnect=true
# Do we export packets over tun/tap virtual interfaces?
tuntap_export=false
# What virtual interface do we use
tuntap_device=kistap0
# Packet filtering options:
# filter_tracker - Packets filtered from the tracker are not processed or
# recorded in any way.
# filter_export - Controls what packets influence the exported CSV, network,
# xml, gps, etc files.
# All filtering options take arguments containing the type of address and
# addresses to be filtered. Valid address types are 'ANY', 'BSSID',
# 'SOURCE', and 'DEST'. Filtering can be inverted by the use of '!' before
# the address. For example,
# filter_tracker=ANY(!"00:00:DE:AD:BE:EF")
# has the same effect as the previous mac_filter config file option.
# filter_tracker=...
# filter_dump=...
# filter_export=...
# filter_netclient=...
# Alerts to be reported and the throttling rates.
# alert=name,throttle/unit,burst
# The throttle/unit describes the number of alerts of this type that are
# sent per time unit. Valid time units are second, minute, hour, and day.
# Burst describes the number of alerts sent before throttling takes place.
# For example:
# alert=FOO,10/min,5
# Would allow 5 alerts through before throttling is enabled, and will then
# limit the number of alerts to 10 per minute.
# A throttle rate of 0 disables throttling of the alert.
# See the README for a list of alert types.
alert=ADHOCCONFLICT,5/min,1/sec
alert=AIRJACKSSID,5/min,1/sec
alert=APSPOOF,10/min,1/sec
alert=BCASTDISCON,5/min,2/sec
alert=BSSTIMESTAMP,5/min,1/sec
alert=CHANCHANGE,5/min,1/sec
alert=CRYPTODROP,5/min,1/sec
alert=DISASSOCTRAFFIC,10/min,1/sec
alert=DEAUTHFLOOD,5/min,2/sec
alert=DEAUTHCODEINVALID,5/min,1/sec
alert=DISCONCODEINVALID,5/min,1/sec
alert=DHCPNAMECHANGE,5/min,1/sec
alert=DHCPOSCHANGE,5/min,1/sec
alert=DHCPCLIENTID,5/min,1/sec
alert=DHCPCONFLICT,10/min,1/sec
alert=NETSTUMBLER,5/min,1/sec
alert=LUCENTTEST,5/min,1/sec
alert=LONGSSID,5/min,1/sec
alert=MSFBCOMSSID,5/min,1/sec
alert=MSFDLINKRATE,5/min,1/sec
alert=MSFNETGEARBEACON,5/min,1/sec
alert=NULLPROBERESP,5/min,1/sec
#alert=PROBENOJOIN,5/min,1/sec
# Controls behavior of the APSPOOF alert. SSID may be a literal match (ssid=) or
# a regex (ssidregex=) if PCRE was available when kismet was built. The allowed
# MAC list must be comma-separated and enclosed in quotes if there are multiple
# MAC addresses allowed. MAC address masks are allowed.
apspoof=Foo1:ssidregex="(?i:foobar)",validmacs=00:11:22:33:44:55
apspoof=Foo2:ssid="Foobar",validmacs="00:11:22:33:44:55,aa:bb:cc:dd:ee:ff"
# Known WEP keys to decrypt, bssid,hexkey. This is only for networks where
# the keys are already known, and it may impact throughput on slower hardware.
# Multiple wepkey lines may be used for multiple BSSIDs.
# wepkey=00:DE:AD:C0:DE:00,FEEDFACEDEADBEEF010203040 50607080900
# Is transmission of the keys to the client allowed? This may be a security
# risk for some. If you disable this, you will not be able to query keys from
# a client.
allowkeytransmit=true
# How often (in seconds) do we write all our data files (0 to disable)
writeinterval=300
# Do we use sound?
# Not to be confused with GUI sound parameter, this controls wether or not the
# server itself will play sound. Primarily for headless or automated systems.
enablesound=false
# Path to sound player
soundbin=paplay
sound=newnet,true
sound=newcryptnet,true
sound=packet,true
sound=gpslock,true
sound=gpslost,true
sound=alert,true
# Does the server have speech? (Again, not to be confused with the GUI's speech)
enablespeech=false
# Binary used for speech (if not in path, full path must be specified)
speechbin=flite
# Specify raw or festival; Flite (and anything else that doesn't need formatting
# around the string to speak) is 'raw', festival requires the string be wrapped in
# SayText("...")
speechtype=raw
# How do we speak? Valid options:
# speech Normal speech
# nato NATO spellings (alpha, bravo, charlie)
# spell Spell the letters out (aye, bee, sea)
speechencoding=nato
speech=new,"New network detected s.s.i.d. %1 channel %2"
speech=alert,"Alert %1"
speech=gpslost,"G.P.S. signal lost"
speech=gpslock,"G.P.S. signal O.K."
# How many alerts do we backlog for new clients? Only change this if you have
# a -very- low memory system and need those extra bytes, or if you have a high
# memory system and a huge number of alert conditions.
alertbacklog=50
# File types to log, comma seperated. Built-in log file types:
# alert Text file of alerts
# gpsxml XML per-packet GPS log
# nettxt Networks in text format
# netxml Networks in XML format
# pcapdump tcpdump/wireshark compatible pcap log file
# string All strings seen (increases CPU load)
logtypes=pcapdump,gpsxml,netxml,nettxt,alert
# Format of the pcap dump (PPI or 80211)
pcapdumpformat=ppi
# pcapdumpformat=80211
# Default log title
logdefault=Kismet
# logtemplate - Filename logging template.
# This is, at first glance, really nasty and ugly, but you'll hardly ever
# have to touch it so don't complain too much.
#
# %p is replaced by the logging prefix + '/'
# %n is replaced by the logging instance name
# %d is replaced by the starting date as Mon-DD-YYYY
# %D is replaced by the current date as YYYYMMDD
# %t is replaced by the starting time as HH-MM-SS
# %i is replaced by the increment log in the case of multiple logs
# %l is replaced by the log type (pcapdump, strings, etc)
# %h is replaced by the home directory
logtemplate=%p%n-%D-%t-%i.%l
# Where state info, etc, is stored. You shouldnt ever need to change this.
# This is a directory.
configdir=%h/.kismet/
ethernin
2010-11-19, 06:23
Hey guys, I just want to say first off that this is a great forum and has answered a lot of questions to help get my n900 into a fully function wireless sniffer! YAY!
I know there has been some talk of injection on this forum, obviously because that's the first thing you want to do with aircrack-ng! I don't know if anyone here has come across the injection driver for the wl1251 card in the n900. But I KNOW it exists. There is even a module I have yet to find called wl1xx.ko which apparently is the patched injection driver. Also there are a bunch of videos on youtube right now of people cracking it:
http://www.youtube.com/watch?v=I6NcP3Fk-hc&feature=fvw
who apparently aren't the neopwn guys, which definitely have the injection driver! Don't know if they are willing to hand it out but I will ask them as well.
So my question is, has anyone come across this patched injection driver and can they PLEASE FOR THE LOVE OF GOD post a link to it? I will be forever great full, again, awesome forum, great admins thanks for all your work!
Hi,
I am also the developer of the injection patches. I originally developed them for Neopwn, but as it seems that Neopwn is stuck I will eventually publish them differently. Please just be patient for another week. Until then I should have cleared the situation with the Neopwn project.
Regards,
lxp
Hi,
I am also the developer of the injection patches. I originally developed them for Neopwn, but as it seems that Neopwn is stuck I will eventually publish them differently. Please just be patient for another week. Until then I should have cleared the situation with the Neopwn project.
Regards,
lxp
wow. this is good news from you. we are eagerly and patiently waiting for this:D
Creamy Goodness
2010-11-19, 07:09
ethernin: we aren't allowed to distribute neopwn or the injection driver here, so asking for it won't get you very far. unfortunately the beta version was a "give me $20 and you can try it" deal, and that was like 6 months ago and they never gave any more updates to the project. they also stopped accepting donations. lxp is at least giving us some hope here, so i won't disrespect him and post any hints about where to find it.
ethernin, you should really allow private messages, in case, you know, someone needs to send you something... completely unrelated, of course.
mrexcess
2010-11-24, 23:11
great news from lxp as i know alot of us are wanting this.:rolleyes:
arnoldux
2010-11-25, 04:49
thank you very much Ixp, i will wait for your next posts, and have some patience on you uploading new inyectiion drivers made by you
i really hope ypu can do this and for the new drivers to be compiled within the kernel power for everyone to se, like the monitor mode ones
thank you again for your great effort and for your kindness for allowing us to use ur stuff
cheers
hardkorek
2010-11-25, 06:06
It would be awesome LXP.
If you need testers just PM me.
I just want to give some updates regarding the packet injection driver:
I will definitively publish the patches on my own, because Neopwn hasn't answered my mails even one week after the deadline I set.
I am currently working on fixing a bug with managed/station mode. I have already invested much time into debugging this bug, but I still need some time to get the optimal workaround. (It seems to be a firmware issue.)
After I have fixed the bug I will forward-port the patches onto the current wireless-testing tree and do some testing with the current power kernel. Right before testing I also have to update my phone to PR1.3. (Still had no time to do that)
great news lxp, thx a lot!
naturegodtm
2010-12-02, 03:07
how do u develp the driver? assembyly code?? programing language?? could u plz tell me?
arnoldux
2010-12-02, 05:08
it would be AWESOME if you could develop inyection drivers for the most recent kernel power, i am currencly using the inyection ones from neopwn and i had to install neopwn, dont want that i wanna use my mmc for other things like nitdroid lol
wish you success for the new drivers
cheers
I just want to give some updates regarding the packet injection driver:
I will definitively publish the patches on my own, because Neopwn hasn't answered my mails even one week after the deadline I set.
I am currently working on fixing a bug with managed/station mode. I have already invested much time into debugging this bug, but I still need some time to get the optimal workaround. (It seems to be a firmware issue.)
After I have fixed the bug I will forward-port the patches onto the current wireless-testing tree and do some testing with the current power kernel. Right before testing I also have to update my phone to PR1.3. (Still had no time to do that)
thank you very much mate, your work is awesome, is unbelievable that the neopwn people dont even answer you, i think that people dont deserve no one $ from the people buy the software and donate and even to talk again about neopwn.
how do u develp the driver? assembyly code?? programing language?? could u plz tell me?
First I haven't developed a new driver. It is still the normal wl1251 driver included within the Linux kernel. Like most of the Linux kernel, also the wl1251 driver is written in C.
it would be AWESOME if you could develop inyection drivers for the most recent kernel power, i am currencly using the inyection ones from neopwn and i had to install neopwn, dont want that i wanna use my mmc for other things like nitdroid lol
Of course, the latest power kernel will be supported.
I will include a new modified power kernel, when I publish the driver. After that the required changes will hopefully be incorporated into the power kernel itself, so we don't need modified power kernels in the future. (To not confuse people: that doesn't mean power kernel will support packet injection "out-of-the-box", it only means that the power kernel should then be compatible with compat-wireless)
pinoverclock
2010-12-02, 21:28
Hi, i don't know if this is the correct place to ask this.
I've been trying to compile rtl8187.ko (r8187) for N900 and kernel-power v46... (Thanx to h-e-n)
Ok got it compiled but ...
ieee80211_crypt-rtl.ko
ieee80211_crypt_wep-rtl.ko
ieee80211_crypt_tkip-rtl.ko
ieee80211_crypt_ccmp-rtl.ko
ieee80211-rtl.ko
insmoded ok
but r8187.ko fails to insmod
insmod: error inserting 'r8187.ko': -1 Unknown symbol in module
I'm using this source http://dl.aircrack-ng.org/drivers/rtl8187_linux_26.1010.zip
Can someone try to compile with scratchbox?
paulkoan
2010-12-02, 22:05
That is your third cross-post for this issue.
pinoverclock
2010-12-03, 14:50
Sorry for that, i´ve been researching threats about this issue, and it seems to be lost in space.
I suppose im starting to get desperate.
Radicalz38
2010-12-13, 16:31
Just bumping this thread...
Any updates for the modified drivers release?
Radicalz38
2010-12-16, 16:43
Another bump only for this post.
I just want to give some updates regarding the packet injection driver:
I will definitively publish the patches on my own, because Neopwn hasn't answered my mails even one week after the deadline I set.
I am currently working on fixing a bug with managed/station mode. I have already invested much time into debugging this bug, but I still need some time to get the optimal workaround. (It seems to be a firmware issue.)
After I have fixed the bug I will forward-port the patches onto the current wireless-testing tree and do some testing with the current power kernel. Right before testing I also have to update my phone to PR1.3. (Still had no time to do that)
Another update regarding the packet injection driver:
It seems that I finally found the firmware issue causing the bug in managed/station mode. It wasn't too easy to figure this out due to the closed-source firmware, but I found a workaround.
Today I have successfully verified it at various locations and now I am continuing with upgrading my phone to PR1.3 and forward-porting the patches to current wireless-testing.
If nothing went wrong I may release the driver before Christmas.
Radicalz38
2010-12-19, 22:55
*Cheers* lol You made my day lxp! ^_^
Gents,
Is there a repo I need to add to see the wireless-testing tree?
Thanks!
houz
No. Patches are going upstream and will get backported by the required people. Please wait until the kernel is released publicly, and any accompanying drivers can be compiled and provided.
Almost X-mas......I by no means am demanding a thing from lxp (it will be done when it's done....and all that...), but I will say that this xmas present is something I think I'm looking forward to more than anything physical....minus gf physical gifts. :)
mrexcess
2010-12-23, 21:23
we're all waiting for this with exitement and it will come in due time so lets not harass lxp. In the end its great just to see some progress on this.
also you have to remember that others will be no-doubt need to be involved in the kernel backporting etc and this is a busy time when they may be busy with family etc. ;)
Sorry that I couldn't release the driver before Christmas. Sadly I run into another bug with current wireless-testing.
A little bit more in detail:
The problem had to do with 4-byte TX buffer alignment for DMA transfer. It wasn't fully implemented yet and current wireless-testing somehow uncovered this.
I am going to run some final tests tomorrow. If the driver passes this test, I will release it within the next days.
handyspacko
2010-12-25, 02:42
Thank you very much LXP for your reply i was waiting for getting your rhhhhhh files. i am so exciting but please take your time make it perfect for us all. THANK YOUUUU
The driver now seems to be stable!
More information can be found in the following thread:
http://talk.maemo.org/showthread.php?p=905982
vBulletin® v3.8.8, Copyright ©2000-2025, vBulletin Solutions, Inc.