Since I wrote the Red Hat + Kismet HOWTO instructions I have received a number of questions on this process and overall wireless networking questions. Here's a FAQ with some of the questions I have received.
Let me know if anyone has any other points that should be added.
1. I have an IBM ThinkPad A30P with a built in PCI wireless NIC. How can I
get this to work?
The IBM A30P's include a PCI version of an Prism card. Currently there have been reports that the orinoco_pci drivers work best for this card. To get this type of wireless NIC to work, add the following lines into the "/etc/modules.conf" file.
alias eth1 orinoco_pci
alias wlan0 prism2_pci
pre-install prism2_pci /sbin/modprobe "-k" "p80211"If you need more information, check out the following site. http://www.geocities.com/dirk_wetter/thinkpad/tp_suse8/
(Thanks PD!)
Make sure that you have the "kernel-source" package installed. The file "/lib/modules/<kernel version>/build" is actually a link that points to the Kernel source code. The link "build" points will point to "/usr/src/<kernel version>/".
You can verify that the Kernel source is installed with the following command:
# rpm -q kernel-source
This command will reply with the version of the kernel-source package that is installed (i.e. "kernel-source-2.4.20-20-9"). If the command returns "package kernel-source is not installed" or the version is not the same Kernel you are running. You must download and install the kernel-source.<version>.rpm.
(Thanks again Scott)
3. I can't get the wireless drivers to work. What can I try to troubleshoot the problem?
Make sure you look for error messages when they actually occur. Linux is usually good about providing lots of error messages when needed. Start from the beginning of the installation and then work your way forward confirming each step.
When trying troubleshoot the wireless drivers there are a number of places to look for errors. The command "dmesg" often contains the most useful information. Also you might try to look for error messages in "/var/logs/messages". You can view these entries with the command "cat /var/log/messages" or open the file in a text editor.
Other items to check include:
- Make sure you actually compiled and installed the drivers. Look for errors during configure/make/make install.
- Are you using the orinoco_cs drivers? Did you successfully patch the drivers?
- Make sure the correct drivers were loaded - look at the entries in "dmesg" and "/var/log/messages". Did the version of the driver you just compiled match the version loaded?
- Did the drivers load (i.e "hermes.c: 4 Dec 2002 David Gibson")? Was the NIC assigned to an interface (i.e. eth1, wlan0, etc)? You should see both of these occur in "dmesg". Here working examples from Orinoco, Prism, and Atheros cards.
- Use the commands "iwpriv" or "ifconfig" to make sure you have wireless interface. Make sure the interface is up ("ifconfig <interface> up").
- If you don't understand the error messages, Google the error to find an answer. You would be amazed how many others have had your same issue.
4.
I can't get Kismet to start. What can I try to troubleshoot the problem?
First make sure you read the error that Kismet is reporting. Most often Kismet provides more then enough detail to determine the source of the problem. Here are a couple of suggestions to try.
- Did you change the required parameters? In most cases these include the "suiduser" (user account Kismet will run under), and "source" (the wireless interface kismet should use)
- Where are you storing your Kismet logs/dumps? Did you add a path to specify the exact path they will be stored or are they going to the directory where you started Kismet? Does the user you specified have permissions to write to this directory? Remember when you start Kismet, it will run with the permissions set in the "suiduser" field. For example, the user "Ritchie" would (should) not have permissions to write to "/root/". You will see a permissions error when you start Kismet if the user account does not have permissions to write the logfiles. You have three options 1) Change the "suiduser" in "kismet.conf" file so that is has permissions. 2) Start Kismet in a different directory 3) Hard code a path that "suiduser" has permissions to access. This permission issue will generate the following error:
FATAL: Dump file error: Unable to open dump file Kismet-Jul-08-2003-1.dump (Permission denied)
- Did you read the Kismet documentation? Kismet changes frequently (Kudos dragorn for all the work).
Kismet has recently (Dec 7, 2003) included full support for 802.11 a/b and a/g combo cards. Currently there are two different drivers for Atheros based wireless NICs in Linux. The two drivers are the Ar5k drivers and the MadWiFi drivers. Unlike the Ar5k drivers that only allow you to place the card into monitor mode, the MadWiFi drivers have the ability to connect to a wireless network - functionality you really would want anyway. The 20030802 release of the MadWiFi drivers do not support monitor mode, but the CVS version includes this functionality. You can find the MadWiFi drivers at http://sourceforge.net/projects/madwifi/.
The Ar5K driver includes the ability to initialize a/b/g combo card, but getting the card to receive wireless traffic in monitor mode is still a major next step. The current Ar5K Linux drivers for 802.11a cards only work with a limited number of chipsets, and can only receive traffic. The current driver support only a limited number
6. What type of wireless NIC should I buy?
If I were to buy my first wireless NIC, I would purchase the Orinoco Gold card. I like the signal quality and sensitivity of the Orinoco cards, plus the option for an external antenna. Support is solid on both Linux and Windows for these cards.
My second choice would be a Prism II based wireless NIC (Some SMC, Linksys, D-Link, Netgear cards) . I like to use the hostap drivers with a Prism based card to turn my laptop into an AP in "special" circumstances. I own the SMC 2632W.
Once in a while I use my Atheros based 802.11a card. I own the SMC 2735W card. Just recently I purchased a Proxim 802.11a/g ComboCard - 8480-WD and have been happy with it so far.
In Windows I like the wireless NICs from Cisco, but in Linux, there are several stability issues with the drivers. I personally have noticed that when a Cisco card is placed in monitor mode, they often stick to one channel.
The Kismet website contains a list of wireless cards that are known to work. You can find this at http://www.kismetwireless.net/cards.html.
7. Once I upgraded my Red Hat 9.0 Kernel, all of my PCMCIA devices stopped working. Or once I installed the wireless drivers, all of my PCMCIA devices stopped working.
There was a bug in several of the Red Hat 9.0 Kernel update RPM packages. Once you upgrade, you will loose the ability to use any PCMCIA devices. This same error also seems to occur occasionally after you install the wireless drivers. With the wireless drivers it's not very consistent, but occurs sometimes. If you run "dmesg", you will see the following error with the "ds" module:
<snip>
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
ds: no socket drivers loaded!
<snip>Just follow the suggested modifications to the file "/etc/rc.d/init.d/pcmcia" mentioned in the following document http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53584 .
8. Once I have already run Kismet, I can't seem to use my wireless card again. I have removed the card and run the command "service pcmcia restart". How can I use my card again without rebooting?
I have only experienced this issue with Red Hat 9.0. It appears once the card is physically removed from the interface is never brought down. If you run an "iwconfig" after removing you card, you will see that the card interface still appears to be active.
I haven't looked for a better solution yet, but will at some point. Just bring the wireless interface down with the following command - "ifconfig eth1 down".
9. How can I get Kismet to work on a Linux distribution other then Red Hat?
I've been using Red Hat since about the 3.x series, so I've stuck with it (so far). Unfortunately, I am not very familiar with other Linux distributions. Although the Red Hat + Kismet HOWTO instructions are fairly generic and should work on many different platforms, some modifications may be necessary. There are a number of different guides for other platforms.
Does anyone recommend a particular guide for other platforms or distributions?
10. How do I install Kismet on Mandrake 9.1
Patch Mandrake 9.1 with the basic steps from the Red Hat + Kismet HOWTO instructions. The only major difference is that Mandrake stores all the drivers in "/wireless" gziped. This means that all the drivers, orinoco.* and hermes.* would have to be zipped with gzip to work on boot/reboot/pcmcia restart.
Once this is done, simply run "service pcmcia restart" and the drivers should work.
Just check to make sure the drivers have loaded with "iwpriv".
(Thanks Tim P.)
11. Is it possible to detect a 802.11g network with an 802.11b card?
Yes. Since 802.11g was designed to interoperate with 802.11b, the management frames must be sent using an encoding that 802.11b cards can detect. Using this principle, it is also possible to detect a modified 802.11b standards such as a D-Link "Turbo" which is based on TI's 802.11b+ and operates at 22 Mbps.
Nothing against Netstumbler. It has its uses, but Kismet will always be able to detect more networks and has more features. Netstumbler is an active scanner, Kismet is a passive scanner. Active scanners have far more benefits then a passive scanner.
Active Scanners
An active scanner works by sending out numerous probe requests to try to associate with an access point. An active scanner will send out probe requests (usually with "ANY" SSID) and must complete a full association to detect an access point. This requires the client to send an association request, the access point replies with a probe response, the client then sends an association request, and the access point response with an association request reply. Active scanners include most wireless NIC managers (clients), Netstumbler, Wellenreiter v1.x, or Aerosol (many others).
Pros:
- Easy to implement on almost any platform
- Included in most wireless NIC clients utilities
- Advanced active scanners can test the configuration of the access points (e.g. look for default passwords)
Cons:
- Not able to monitor packets - You can't watch the frames (which might include passwords!) as they are transmitted
- The range or distance to required an access point is more limited. You must have a strong enough signal to create the two way communication to associate.
- More time in a particular spot is a required to detect a network. You must remain in a spot for a longer period for the full association to occur.
- Active scanners are always sending out probe requests and can be detected
- Additional legal considerations when connecting to other networks
- Unable to detect cloaked or restricted networks (unless the client configured with the SSID of the cloaked or restricted network)
Passive Scanner
Passive scanners, unlike active scanners do not transmit any packets. They work by monitoring the RF transmissions that are emitted by 802.11(X) equipment. This method not only enables the detection of access points, but also allows the detection of wireless clients and the ability to collect every packet that is transmitted by a wireless network. Passive scanners include Kismet, Discoverer, Wellenreiter v2.X, and many of the commercial tools.
Pros:
- Only 1 frame is required to detect a wireless device (APs transmit approximately 10 beacons per second - not to even count any real network traffic - e.g. you chance chance of detecting a wireless network is significantly greater)
- Able to detect nonbeaconing/cloaked/restricted access points
- Able to detect access points, peer-to-peer networks, and searching (probing) clients
- Able to view or analyze the packets that are transmitted (better watch you passwords - POP clients)
- Does not need to transmit a single packet to detect access points (impossible to detect someone with a passive scanner - maybe this should be a con for come people!)
Cons:
- Currently wireless NIC drivers that are capable of monitor mode are more limited. For Windows, only commercial drivers are available for lots of $$$.
13. What is a cloaked network (broadcast SSID setting)?
A standard access points transmit approximately 10 beacon frames per second to announce its presence. The 802.11 and 802.11b standards state that the AP's SSID is to be included in each beacon frame. Manufactures have tweaked this behavior to increase the security of the wireless networks.
A cloaked network is an access point that does not transmit the SSID in each beacon frame (zero length SSID or the length of the SSID, but zeroed out). This makes it a bit more difficult to detect the SSID of an access point. A cloaked network does not entirely hide the access point's transmission of the SSID. Over time, the access point must transmit the SSID.
Kismet can identify a cloaked AP because it still sees the beacon frames (with a zero length SSID). These are displayed in Kismet as <no ssid>. After time, a client will connect to the AP by sending a probe request which will transmit the SSID. Additionally, after the Access Point accepts this SSID, it will reply with a probe response frame that will include the SSID. Kismet will see this transaction and display the identified SSID (from the probe response) between the carrots (i.e. <the transmitted SSID>).
14. What is a restricted network?
Another feature often included in many newer access points is a "restricted" network setting (often part of the broadcast SSID setting). This setting requires the the client to "know" the specific SSID of the access point before you can connect. Often clients are configured to use the "any" SSID setting, which is a probe request frame with a zero length SSID. Most access points allow the "any" SSID to connect; a restricted network would not allow the "any" SSID to connect. A restricted network is invisible to Netstumbler (unless you know the SSID, and configured the client to probe for it.). Kismet will detect the access point because it will still transmitted beacon frames or the SSID included in the probe response.
15. Do you recommend any antennas?
There are numerous antennas to choose from. I've used, purchased, and build a couple different types.
If you want to be crafty:
I would recommend building a Pringles can antenna if you want a couple hour project. Several months back I built the Pringles can antenna (http://www.oreillynet.com/cs/weblog/view/wlg/448) and the Yuban Antenna (http://www.oreillynet.com/pub/wlg/1124 ). The Yuban antenna is much easier to build, but I prefer the Pringles antenna. The Pringles Can antenna works really well and travels well. The only down side is that it is a directional antenna.
If you just want to purchase one:
I have used three pre-fab antennas purchased from HyperLink Technologies and FAB Corp. My favorite antenna is probably the Hyperlink 8 dBi Omni (HG2408U - $80?). It has a good size to it and can be easily held or mounted. I often have this antenna connected to my laptop in a backpack so I can walk around as needed.
The most popular antenna is probably the 5 dBi magnetic mount ($40?). I don't prefer this antenna because I typically War Bike and the magnet doesn't mount well to my bike. Magnetic mount antennas are helpful if you use your car a lot, because they are easy to mount and you don't have to worry about the 8 dBi Omni sliding around on the dashboard.
I have also used a 15 dBi Yagi ($80?) from Fab-Corp. This antenna works well if you really want to search over long distances, in a specific direction or if you really want to pinpoint the direction of an AP.
In some cases you might not want one:If you are doing an assessment in a very noisy area, such as an office space in downtown Chicago, I typically do not use an antenna at all. When it comes to 802.11b, it travels far enough that Kismet should detect it a floor above, below, or while passing the floor on the elevator. It is often much easier to pinpoint an AP without an antenna. I often even switch to my Prism 2 based card because with the weak built in antennas, you know you are really close to the AP.
16. How do I stop the error "Error -5 writing packet to BAP"?
Starting mainly with a default install of Red Hat 9, I have experienced reliability issues with Kismet when using Orinoco cards. Whenever I experience the issue I always find the error message "eth1: Error -5 writing packet to BAP" when I run the command "dmesg". If I see this error, Kismet was probably acting very goofy (technical term).
Here's a solution from Dekonta that will completely alleviate the issue:
"My solution? Disable the hotplug event for the card that causes the interface to automatically be raised when inserted. In Redhat, edit /etc/hotplug/net.agent and comment out the "exec /sbin/ifup $INTERFACE" line. Now you can insert the card, raise eth1 manually if you wish, or put the card in monitor mode, change your MAC address, or whatever else you'd like without that pesky autoraise occuring.
Since doing this, I haven't had one BAP error."
To find out more information about this error, you might check out the original posting at: http://www.kismetwireless.net/Forum/General/Messages/1058245225.517217
17. How can I monitor one channel with Kismet and disable Kismet hopper?
There are several situations where you might only want to monitor one channel. One example is if you wanted to try to capture every packet from a specific source. If Kismet hopper is enabled, you would miss a significant number of packets transmitted from your source while you wireless NIC was listening on a different channel.
When you start Kismet you want to use the -X and -I commands. The -X command disables the channel hopper. The -I command specifies the initial channel to listen on.
# kismet -X -I <capturename in kismet.conf>:<channel>
An example of this command would be:
# kismet -X -I orinocosource:6
18. How do I fix the error "error while loading shared libraries"?
The full error received is shown below:
#[root@localhost kismet-devel]# kismet
Server options: none
Client options: none
Starting server...
Waiting for server to start before startuing UI...
/usr/local/bin/kismet_server: error while loading shared libraries: libwiretap.so.0: cannot open shared object file: No such file or directoryThis one is easy to fix. You need to create the necessary links to the Ethereal shared libraries. Just type in the following command:
# ldconfig
Copyright 2004 Tipsybottle.com - All rights reserved.