Security optimize

Beacon frames, 802.11 devices, and Kismet

Scott Reeves follows up on his introduction to the Kismet network monitor to examine how it uses beacon frames to detect devices on a 802.11 network.

Last post was an introduction to kismet. This week follows up by explaining how kismet uses beacon frames to build up a list of devices associated with a 802.11 network and how knowing how many devices are on a network can help you to reduce the possibility of interference and consequent lower throughput. The version of kismet used in this case is Kismet-2011-03-R2.

A note on the terminology used in this post. An access point here refers to a 802.11 router; a wireless station could be any 802.11 enabled device, such as a laptop, tablet or smart phone.

As was mentioned last week, the way that kismet commonly detects a wireless access point is when it receives a beacon frame. A beacon frame falls into the class of frames known as management frames. In 802.11 a beacon frame is sent out periodically by the Access Point, typically every 0.1 seconds.

So what is a beacon frame? A wireshark capture of a beacon frame is shown in Figure A.

Figure A

Click to enlarge

This frame contains several important pieces of information. It includes the SSID of the station. The interval between beacons is included. There is a time stamp on the frame.

A wireless station uses a beacon frame to determine which access point to connect to. Once it has determined which access point to use, the wireless station sends an association request. The access point will reply with either an acceptance of the request or a rejection.

As mentioned above, a beacon frame is sent out every 0.1 seconds. Most 802.11 routers have this as a default setting. Many routers allow you to change it to as low as 20ms (0.02 seconds) right up to 1000ms (1 second). Changing from the default value of 100ms is therefore possible, but you need to be aware of possible impacts. A beacon frame uses up bandwidth, so sending a frame too often will eat into the available bandwidth. On the other hand, wireless stations will be able to connect to the access point rapidly.

Conversely, sending a beacon frame infrequently can cause delays for wireless stations attempting to connect to the access point. This is because a wireless station will work its way through all the channels looking for a beacon frame. If the beacon interval is set high then the station takes more time to receive a beacon. This may not necessarily be a problem if the network is largely static, but it will mean a longer association time. The upside is that the throughput may improve.

Kismet also detects frames from wireless stations. Listening to exchanges between access points and wireless stations enables kismet to build a list of devices associated to an access point. Other wireless stations can create extra noise and congestion, so being able to build a picture of how many devices are using a channel helps in estimating which channel to use. Figure B shows a list of devices associated with the wireless router "nogudar". This network is my own test lab. There are four devices associated with the access point. The access point uses channel three.

Figure B

Click to enlarge
Consider the scenario in Figure C. Two access points use the same channel. They are far enough apart that they don't directly interfere with each other, though kismet will detect both.

Figure C

Click to enlarge

The problem arises with two wireless stations that are in an area where they can attach to their respective access points, but can also interfere with each other's transmissions. This is likely to cause retransmissions and a consequent lowering of throughput. Add in more wireless stations and the problem can escalate. For this reason, it is prudent to note channel usage and how many devices are associated to an access point.

In summary, kismet can provide some insight into how your 802.11 network is running, but it can also give you some good insights into whether channels are heavily congested. It can identify cloaked networks over a period of time, which can further assist in eliminating sources of interference.

About

Scott Reeves has worked for Hewlett Packard on HP-UX servers and SANs, and has worked in similar areas in the past at IBM. Currently he works as an independent IT consultant, specializing in Wi-Fi networks and SANs.

0 comments