WifiNigel

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