In this section, we'll take a look at wireless connection issues and how they look in Wireshark.

The 802.11 standard has been around for quite some time. You can find more info at http://ieee802.org/11/Reports/802.11_Timelines.htm:

It originally started in 1997. You can see in the preceding screenshot that this was the year it was ratified. It actually began in 1991. Since then it has had many changes to it, including 802.11a, which some people may remember. We have 802.11b, 802.11g, and so on. As we go up in time, you can see how many different flavors of 802.11 there are out there. Now, not all of them have been used for normal home networks or office networks; some of these are specialty versions for long distance or low power such as WiMAX. You can see that all the ones that I've been going through have been superseded by a newer version, and these newer versions are at the top:

These are the ratified standards. You can see that even though 802.11a and b and g and n are still supported by hardware out there, still supported by operating systems, the actual standard is, for example, for this version we're talking about, 802.11ac. So ac actually encompasses the ac standard, the n, the g, the b, the a, and so on. And you can see there are additional versions of 802.11 that are here, such as the one that'll be used for what's called the TV White Space area. So these are sections of bandwidth that are available for potential use and reprioritization by the FCC. We have some additional ones, which are proposed standards, such as ah and ai. Then, there are all these other ones out there that give us additional methods of connecting over longer distances and greater speeds, and things like that. All of this is available on the IEEE website, and you can learn much more about it at http://ieee802.org/.

The following is an example of a packet capture done by a device that could capture the 802.11 frames and provide them to Wireshark:

This is commonly done with a wireless card that is capable of not only enabling promiscuous mode but monitor mode in order to view all of the data that we want for all of the different channels that we use. Additionally, there's spectrum analyzers out there such as Wi-Spy and others that are dongles that you can attach to a laptop or something like that; you can go around and investigate the spectrum analysis side of things.

So we're looking at packet captures, but remember there's more to it than just the packet captures. Wireless brings in a whole slew of additional issues such as signal strength and interference with other devices. But looking at the actual data, it shows as essentially Ethernet. I looks like Ethernet to us when we capture it, and that's done on purpose; the 802.11 standard is that it's supposed to look like Ethernet, but over a wireless connection instead of a wired connection. That's to make our life easier and make it more cross-compatible.

And what we see here in the capture is we have the Protocol listed as 802.11, so Wireshark knows that it's an 802.11 capture. This is an 802.11 frame, and it's a Beacon frame:

We see there's Beacon frame and there are some flags. We have a Frame Control Field. We have the Receiver and Destination; it looks very similar to what you'd expect on layer 2 on a wired network. You have a from and a to MAC address, and you've got some additional information: some additional flags, and so on. Now, of course, there are some other options in here for it to work on wireless, such as our BSS Id: what device we are connected to, what access point we are connected to; and what kind of frame this is, because there are different kinds of frames in 802.11:

We, of course, have our Frame check sequence, just like we had with the standard Ethernet.

Now, what is a beacon frame? A beacon frame is transmitted normally every 100 milliseconds by an access point in order for it to declare to all of the listening devices that it is providing the following network; that it is beaconing; and that it can support the following network name. You will see a lot of beacon frames in a wireless capture. They occur constantly. If you do not see them constantly, then that is a potential issue. Now, if you want to filter, or if you have a packet capture that includes other erroneous packets in it and other frames, or if you want to filter only your wireless traffic, you can do the wlan filter:

If you use wlan, that will include all of the 802.11 protocol frames. Something else that you might also want to do (leave wlan filter on) is not show beacon frames. Let's say that you know for a fact after looking through things that beacon frames are consistent and everything is good with them; then we don't need to worry about them.

What we'll do is right-click on the Beacon frame in the packet details and go to Apply as Filter | Not Selected:

This way, we are selecting all of the wireless LAN frames, but not anything that is a beacon. And that really trims down our capture:

Now, we see only the probe requests, the responses, and some data.

Speaking of beacons, here's an example of a capture with a whole lot of beacons. Everything is just constantly beacons, beacons, and beacons everywhere:

A common problem that can occur in wireless is a drop in beacons due to some sort of problem on an access point. It could be the signal-strength issue or the firmware on the device, a bad antenna, and so on. It could be anything. But a drop in beacons will cause clients to drop their connection to the wireless network because they think the wireless network has disappeared. So the capture shown in the preceding screenshot includes a problem with beacons, but we don't really see anything pop up that's obvious. Nothing's bright red, popping up to us; there are no changes really; it's just all consistent. So how do we see the problem?

Remember back to the section on statistics. Now, go to Statistics | I/O Graph on our beacons:

We can see that we absolutely have a drop that shows us we've got a problem with our access point:

Make sure you certainly use your graphing capabilities when doing wireless troubleshooting because there are a lot of variables that are not controllable by us due to the nature of it transmitting over radio waves. We need to do a lot more visualization in order to see what's going on, especially when you have thousands and thousands of frames like this and there's a problem in there, but you don't know where, and exactly to what extent. Using graphing can be a very big help for you.

Additionally, we have a capture that shows a signal issue:

So, we'll do a ping. We have (ping) request, (ping) reply, and so on. Now just scroll down through the capture and see if you find anything that's odd or an obvious problem.

As we scroll through, we can see all Echo (pings): request and reply repeatedly. Do you see any problem? Well there is a very obvious problem.

As we scroll through, look at the fact that we have so many requests and very few replies. That is a very blatant problem. If we go into the expert information, we can see in the warnings that it says No response seen to ICMP requests:

Of course, you know that as we click through each request, it'll show us each packet along the way. We have all these requests that did not receive a reply, but you don't see any other problems in the capture.

Now remember, ICMP does not offer any sort of stateful connection like TCP does, for example, so we don't get any responses that indicate that there are really any problems. We just make an attempt, it fails, and we just keep attempting over and over again. So being able to take a look at what's in the capture, even just scrolling through it and taking a look at what the pattern looks like, can be useful because we don't really have much else to go on.

Now of course, you could also graph this out and have two graphs, one that requests and one that replies, and you can see how they may not match up in the I/O graph. This is indicative of a signal issue, so what we're looking at here is we have some data packets that are making it and some that aren't. However, in the capture, it'll not tell us the signal strength anywhere. We have to determine what the problem is based on the information we have, and from looking at this it looks like a signal problem because we have packet loss. Now, on the testing device, you'll most likely see that in your command window it'll say that so many packets have been lost during the following ping attempts. In the drivers, you may see that the wireless signal is low. There are other ways you can look at this, but if you're looking at just a pure packet capture of ICMP, this is an example of what the problem would look like, such as a low signal issue.

Wireless is a vast topic that is very in-depth, and I highly recommend you spend time going through a full wireless course or a series of books to learn it if you are going to end up supporting that and that's something you're interested in doing.

A short video or book on how to look at it in Wireshark and what certain things might look like in a Wireshark capture is useful, but there's much more going on with wireless because we're using radio waves and signal strengths and such. Thus, it's highly recommended to go out and learn more about wireless in order to understand how things really work behind the scenes.