WifiNigel

Wireshark has an expression builder to help build filter expressions to filter out the frames that perhaps you don't want to see, or to allow you to select the frames would like to view. At first glance, the categories are pretty overwhelming due to the fantastic array of protocols that Wireshark can decode for us. I certainly had to dig around a little the first time I looked through the list before I found the WiFi related categories. I thought it might be useful to list the categories (that I have found so far!) that relate to WiFi traffic.  Here is the list, together with a brief description of each one: 802.11MGT - IEEE 802.11 Wireless LAN management frame 802.11MGT - Radiotap - IEEE 802.11 Radiotap Capture Header IEEE 802.11 - IEEE 802.11 wireless LAN IEEE 802.11 Aggregate Data - IEEE 802.11 wireless LAN aggregate frames Wi-Fi P2P - Wi-Fi Peer-to-Peer

I quite like to be able to see the frame type, sequence numbers and flags field when looking at a summary of an 802.11 capture in Wireshark.  However, Wireshark can be too helpful when decoding frames and  will display a summary of the frame which shows the detail of hight layer protocols (thus hiding the 802.11 summary info). This generally happens when decoding a capture of a WiFi network that has a guest network that is not using over the air encryption. Here is an example. Some data frames in the trace summary below are shown as ' https ' or ' Application Data ' frames, rather than layer 2 data frames: To prevent this behaviour, simply go to the " Analyze > Enabled Protocol" menu option in Wireshark and de-select 'LLC ': This will restore the standard 802.11 frame summary so that 802.11 frame types, flags etc. are available: One thing to bear in mind with this approach is that some exchanges you would normally decoded (e.g...

Generally, when capturing and decoding frames in a wired network, there isn't a huge amount of interest going on at layer 2 of the OSI stack. There is pretty much one type of frame at the data link layer (i.e. an Ethernet frame), with all of the real 'interesting' stuff going on in layer 3 and above. However, when looking at 802.11 wireless packet capture and decoding, there are a whole host of different frames types at layer 2 that we might see. ( As a side note, layer 3 and above are often inaccessible to us in wireless captures as the payload of our layer 2 frames may be encrypted, rendering upper layers impossible to view. ) There are actually 3 types of frames we might see at layer 2 when performing a wireless capture: Management frames - these frames are used by wireless stations to join and leave a wireless network Control frames - these are used to assist with the delivery of data frames Data frames - these contain the actual higher-layer data that we want...

Often when looking through a wireless capture file, there may be a number of frames which have been corrupted, but Wireshark has attempted to decode it as best it can. When a frame is corrupted, the frame check sequence of the frame will fail, indicating that some part (or parts) of the frame have errored during transit. When reviewing a trace, it can be very easy to miss the fact that the FCS is wrong and that you are essentially looking at a corrupt frame. This will often manifest itself bizarre frame types and field values which can lead you completely astray in your diagnosis efforts. There are a couple of ways to get around this. Firstly, you can add a display filter to remove all of the frames with a bad FCS ( wlan.fcs_bad == 1 ), but use this option with care (see note below): The drawback to this approach is that just because some frames fail the FCS, the actual frame that arrived at the destination station may have been OK. It depends on where your analyse...

I've been doing some study for my CWAP  (wireless analysis) exam recently, so I've been spending quite some time staring at Wirehsark traces trying to figure out precisely what all of those 802.11 fields actually mean. One thing I noticed whilst pouring over a few capture files is that some of them seemed to have some additional fields included in the trace, which seem to have nothing to do with fields defined in 802.11 frames at all. They are in a section of the packet decode called 'RadioTap Headers'. I wasn't too sure what they were and why they are available in some captures, whilst in others they were missing. After a little bit of research, I found out a bit more information and thought it might be worth sharing in a quick blog post. In summary, radiotap headers provide additional information that is added to each 802.11 frame when capturing frames with an analysis application. Just to be clear, these are not part of the standard 802.11 frame form...