Ask Your Question

Persistent problems with Wireshark capturing WLAN high datarate frames

asked 2019-07-24 10:54:35 +0000

esotechnica gravatar image

updated 2019-07-24 22:09:12 +0000

SYN-bit gravatar image

I have never had any luck capturing anything useful with Wireshark in monitor mode. It seems to be a problem with capturing high speed WLAN frames. In a previous post I detail the problems I had with my WLAN adapter not being able to capture all packets unless I downgrade the AP from 802.11n to 802.11b/g.

Assuming that it was the WLAN adapter that was the problem, I have recently purchased an Alfa AWUS036ACM AC1200 WLAN adapter. This is the card recommended by aircrack-ng as the best card for wireless packet sniffing. However, I still have the exact SAME problem as before, I can only see low-rate frames over the air.

Please, can someone tell me is it actually possible AT ALL to capture the high rate frames of 802.11n and 802.11ac, and how I can troubleshoot this issue?

NOTE: I have no trouble setting this device into monitor mode. It sees frames from other stations, just not the ones I need. Decryption works fine too.

edit retag flag offensive close merge delete


What happens if you try using tcpdump to capture the frames?

Guy Harris gravatar imageGuy Harris ( 2019-07-24 17:47:52 +0000 )edit

I don't have enough karma to change the title - perhaps it should read 'high wlan datarate frames'?

Bob Jones gravatar imageBob Jones ( 2019-07-24 20:41:21 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2019-07-24 21:13:14 +0000

Bob Jones gravatar image

Please, can someone tell me is it actually possible AT ALL to capture the high rate frames of 802.11n and 802.11ac, and how I can troubleshoot this issue?

Yes, it is possible. However, the higher the datarate, the harder it will be. Here is an example of some relatively high datarate frames collected:

image description

They are all the same frame, just captured with three different WiFi adapters (there is a fourth adapter that didn't pick it up and I have no idea why). They also don't report the same information - two say it is LDPC encoded, one BEC. Which is correct? Not always obvious to tell (I suspect LDPC is correct). Missing traffic; inconsistent information; behavior that changes as the Linux kernel changes or MacOS updates - such is 802.11 packet capture.

If you search here you will see this comes up often, and many of those discussions provide the root cause: the capture capability envelope has to be at least as big as the test traffic to have any chance. I don't know why you need these frames - solve a problem for work? For fun? Any which way, I recommend a different approach to these types of problems: understand what you need the tool to do, then buy a tool that meets those requirements.

So will you ever be able to see the traffic you need to? No one here can answer that because we have no idea what you need to capture. Once the problem is understood, we can set about looking for a solution. (And yes, there are edge cases that just sometimes do not to work, even if they should).

The master table for 802.11 n/ac is big. I have never seen a device support the whole thing, only a subset. So troubleshooting steps:

What do you need to capture? What are the modulations that need to be collected? We need datarates, spatial streams, channel widths, MCS Index, aggregation, and guard interval (some of these are inter-related). Until you can answer this, we don't know what system you need to collect this traffic. Capturing more than 2 spatial streams gets significantly more complicated.

Be close enough to the test traffic. High datarate frames do not travel very far.

Suggest to use a high end wifi system that can tune traffic - disable/enable certain features so we can calibrate the response of the capture system to gain confidence in it's capabilities. For instance, test with LDPC on and off. Test with 4, then 3, then 2, etc., spatial streams.

The beacons and probe & association request/response frames provide a lot of information related to capabilities of the AP and the client. Typically, systems will try to use the maximums in common between the two to attain the highest performance. These are low datarate frames, so capturing these is easier and mapping out the capabilities from a packet capture will show you most, if not all, of the required ... (more)

edit flag offensive delete link more


I suppose the short answer to "what do I want to do" is to simply collect every frame broadcast on a particular channel with a particular SSID. When the card is in managed mode, it has no problems collecting these high-rate frames, so why does switching to monitor mode make any difference in this respect? Isn't it just the same thing except you would be dealing with a larger volume of frames (recording all frames rather than just frames addressed to the station). Is the wlan adapter 'not keeping up' with this high volume part of the problem? I admit I know very little about this stuff, but could explain to me in laymen's terms why a device that can do one thing in managed mode cannot do essentially the same thing in monitor mode?

esotechnica gravatar imageesotechnica ( 2019-07-25 04:12:59 +0000 )edit

simply collect every frame broadcast on a particular channel with a particular SSID

Then you need to be sure the capture system is capable of picking up all this traffic, from all of the clients. If all of the clients are known, this is an engineering exercise of matching the performance characteristics and testing. Conversely, it could be possible to get frames from the AP, but in general that is never as good because I find not all traffic is passed, for whatever reason.

managed mode cannot do essentially the same thing in monitor mode

Do the same and essentially the same are not, well, exact. Here is your test, if you have not thought of it already: buy two of those aircrack-ng favorite adapters, and use one in monitor and one in managed. I expect that the monitor should pick up the managed one as you know the capabilities ...(more)

Bob Jones gravatar imageBob Jones ( 2019-07-26 08:53:57 +0000 )edit

NOTE: I have no trouble setting this device into monitor mode

You have not shared your configuration so we can't validate this - I'd suggest setting to 80MHz in monitor mode for this chipset. This chipset is represented as wlan2 in my picture of 802.11ac frames picked up at 867Mbps datarate.

Something like this:

sudo iw dev wlan2 set channel 149 80MHz

Bob Jones gravatar imageBob Jones ( 2019-07-27 18:38:24 +0000 )edit

I've not had any luck setting the adapter channel using iw command. I always get "command failed: Device or resource busy (-16)" every time I use it.

Instead I use 'airmon-ng start <interface> <channel>' which seems to work with setting the channel but the channel width is always 20MHz.

esotechnica gravatar imageesotechnica ( 2019-07-28 00:27:17 +0000 )edit

My 802.11ac AP is configured to channel 44 with a 20MHz channel width with SGI disabled (I override the channel width to 20MHz because I can't change the channel width on capture care as noted above, not sure why...).

The highest rate data packet that I have received is at 156Mbps (MCS 8 with 2 spatial streams). However there must be other frames that the capture card is not capturing, because the capture is not being dissected by any protocol dissectors.

I'm not sure how to analyse the probe responses for the AP, I want to determine what MCS indexes and how many spatial streams are supported, but I have little understanding of what a lot of the info means and can't seem to directly find the info I need. Can I post a wireshark screenshot of the probe response?

The capabilities of the capture card ...(more)

esotechnica gravatar imageesotechnica ( 2019-07-28 01:16:40 +0000 )edit

answered 2019-07-24 14:12:30 +0000

cmaynard gravatar image

If performance is a concern, then I would highly advise you to stop using Wireshark for capturing. Instead, use dumpcap, which is what Wireshark uses under the hood anyway. Alternatively, you could use tcpdump.

This alone may or may not be sufficient though, so for other tips, refer to the Wireshark Performance wiki page, although there are still no guarantees. In the end, you may need external, dedicated capture hardware to obtain the performance you're seeking.

One additional tip not [yet] mentioned on the wiki page, and which may or may not help, is to try increasing the scheduling priority of the capture tool, i.e. by using nice.

edit flag offensive delete link more


Uhm @cmaynard, @esotechnica is not seeing the frames on the high rate WiFi channels instead of not being able to write a high rate of packets to disk. I must admit, the title pushed me in that direction too at first :-)

SYN-bit gravatar imageSYN-bit ( 2019-07-24 14:44:29 +0000 )edit

Please, can someone tell me is it actually possible AT ALL to capture the high rate frames of 802.11n and 802.11ac

Hmm, I thought the problem of not seeing the frames was resolved and the problem was not being able to keep up with the high frame rates? Well, either way, I still think it's possible that some performance improvements can be realized by applying some of the ideas mentioned. It certainly can't hurt.

cmaynard gravatar imagecmaynard ( 2019-07-24 14:51:18 +0000 )edit

Taking care of the performance of the capture process is always good, yes :-)

SYN-bit gravatar imageSYN-bit ( 2019-07-24 15:22:51 +0000 )edit

Sorry for the confusion, I have amended the title, I meant I don't get any high-rate frames at all from the air...

esotechnica gravatar imageesotechnica ( 2019-07-25 04:03:54 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-07-24 10:54:35 +0000

Seen: 2,612 times

Last updated: Jul 24 '19