WifiNigel

I recently created a  video to look at how we understand the data throughput of a wireless client from an over the air Wireshark capture. We take a look at using the I/O Graph feature in Wireshark to achieve this. You can view the video below: References: YouTube video link Metageek Wireshark profile

In a recent Wireshark 3.0.6 capture I noticed that FCS values for captured wireless frames were showing as "Unverified". I wasn't sure why this was the case, as I'm sure that Wireshark usually shows a "good" or "bad"  FCS indication. The image below demonstrates what I saw:   After some googling, I found a note that the FCS check was disabled by defaut in Wireshark 3.0.x as some NICs report the FCS check incorrectly.  The following process details how to re-enable the check:  Go to Edit -> Preferences -> Advanced in Wireshark. Enter "wlan.check" in the search bar: Double click on the "False" word for the attribute "wlan.check_checksum". This will toggle it to "True" (make sure you click on the "False" word, not anywhere else on the line).  Hit OK and see the change immediately in your capture decode: Hope this quick note may help someone in the future (......

Want to be able to capture wireless frames via a WLANPi using just Wireshark on your Windows 10 machine? ...And be able to configure the capture configuration on the WLANPi using just Wireshark too?  Read on... (or checkout the video here ) Earlier this year, I put out a command-line script called WLANPiShark that allowed Windows 10 users to configure a WLANPi and initiate a frame capture stream in to Wireshark. Though a little clunky, it worked quite reliably for most of the time and, judging by feedback I received, was quite popular. As Windows users, we've always been the poor cousins to our Apple brethren who are able to use their Macbook to capture over the air using the internal NIC card of their Mac in monitor mode. Getting a low cost adapter that could be put in to monitor mode on a Windows machine was as rare as hen's teeth. Having access to the WLANPi and being able to fire up WLANPiShark opened up wireless capturing to many folks who have to use Wi...

Wireless traffic capture and analysis can be a tricky business and is often seen as something of a dark art to newcomers to the world of Wi-Fi. There are a huge variety of options when considering how to capture wireless traffic over the air, with many of the solutions being paid-for options that may be out of reach for many individuals. Many people approaching wireless analysis may already be familiar with Wireshark, based on their previous experience on wired networks, where they may have used it for troubleshooting and analysis purposes.  They may wonder if they can use Wireshark for their initial foray into wireless analysis.  Using Wireshark for wireless capture and analysis on Wi-Fi networks can be a little tricky and presents the newcomer with a whole new slew of frame types to learn. There are many good articles, videos and podcasts out there looking at wireless analysis, particularly if Wireshark is your tool of choice. I thought it would be good to pull them ...

*** Note this article is out of date. Please use the information on this page until I get this artcile updated:  https://github.com/WLAN-Pi/WLANPiShark2 *** One huge advantage that Apple Mac users have over owners of Windows 10 machines is the ability to perform a native 802.11 wireless packet capture direct from their built-in wireless NIC. This is extremely useful for wireless pros who want to take a quick over-the air-capture into Wireshark to analyze traffic for troubleshooting purposes. Windows users don’t have the luxury of this native wireless capture capability. In this article, we take a look at how we can use a WLANPi unit as an adapter to capture traffic over the air, straight into Wireshark on a Windows machine. With the WLANPi being powered from the USB of the laptop, this is a super convenient, portable and powerful capture method that gets Windows users a little closer to the capabilities of their cousins on Apple Macs. Background I’ve always felt really bad...

Generally, when performing over the air captures of WLAN traffic with Wireshark, the workflow adopted is as follows: pick a specific channel where target traffic resides switch the capture adapter to that channel capture all 802.11 traffic over the air on that channel Once a sample of traffic has been captured, the capture is stopped and analysis of the traffic using Wireshark's built-in display filters can begin. In most situations, this is the best workflow to adopt. It ensures that all required frames are captured. Filtering wireless traffic while capturing frames is very problematic due to the complexity of 802.11 frame exchanges. It is very easy to miss parts of interactions between stations if you filter traffic as it is being captured. However, there are a few edge cases where it may be useful to filter over-the-air frames at the point of capture. This will mean that only the filtered frames are available to display in Wireshark - all other frames are lost...

In previous articles , I’ve covered a few aspects of wireless frame capture using Wireshark, looking at subjects such as frame colourization and radio tap headers . In this article, I look at another way of improving the visualization of wireless frame captures by adding columns to our Wireshark frame summary, including customised columns that use 802.11 frame field values. Background By default, a typical 802.11 capture in Wireshark looks something like the screen-shot presented below (assuming you added the colourization rules I previously blogged about): Although we get a nice summary of the frame types that are whizzing by, it would be useful if we could get a little more summarized information, before we dive into the detail of each frame. In a wireless environment, there are many more considerations compared to the wired world when we’re looking at frame captures. In addition to the information around frame timings, addressing, types etc. I’m always interested ...

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...