This is our old Q&A Site. Please post any new questions and answers at

Hello, I'm new in using Wireshark, and I wonder if you guys could help me.

I want to capture and check the aggregated packet (A-MPDU or A-MSDU). I want to see its behavior when there is a dropped frame during transfer.

I have:

Router: TP-LINK WR1043ND (802.11n, 2.4GHz)

WiFi Adapter: NetGear WNDA3100 (802.11n, 2.4/5GHz)

  1. How can I capture aggregated packets?
  2. Can I just download a file from a website (from the PC running the Wireshark) and run the capturing in Wireshark?

Your help is much appreciated. Thanks.

asked 05 Jul '16, 22:55

ajebulon's gravatar image

accept rate: 0%

I reviewed the trace and notice there are no beacons. Anyway, I could get some info out of the probe responses for the AP capabilities in your area, but not for the client. The trace is heavily filtered so no probe requests are observed.

You are in monitor and promiscuous mode, so could you share the following output so I can figure out why I can't get mine to do promisc mode:

  1. lsusb
  2. ethtool -i <wireless interface="" name="">
  3. uname -a

I think you are capturing A-MPDU packets, see this sequence of frames from the AP to the client:

alt text

Notice the A-MPDU reference number is the same, and the sequence starts with a RTS, then ends with a block ACK. In addition, there is a signal strength measurement in the header of only the last data frame.

I did not see any any A-MSDU frames in your trace. From 802.11-2012, the QoS element in the 802.11 header has a field which indicates if this frame is an A-MSDU or just an MSDU: A-MSDU Present subfield The A-MSDU Present subfield is 1 bit in length and indicates the presence of an A-MSDU. The A-MSDU Present subfield is set to 1 to indicate that the Frame Body field contains an entire A-MSDU as defined in The A-MSDU Present subfield is set to 0 to indicate that the Frame Body field contains an MSDU or fragment thereof as defined in

The filter I use on your trace is then

wlan.qos.amsdupresent == 1

and indeed, there are none here but at least we can see how to identify them. This field is here, for example:

Frame 2: 1486 bytes on wire (11888 bits), 1486 bytes captured (11888 bits) on interface 0
Radiotap Header v0, Length 32
802.11 radio information
IEEE 802.11 QoS Data, Flags: .p....F.C
    Type/Subtype: QoS Data (0x0028)
    Frame Control Field: 0x8842
    .000 0000 0010 0100 = Duration: 36 microseconds
    Receiver address: Netgear_e7:49:e5 (00:1e:2a:e7:49:e5)
    Destination address: Netgear_e7:49:e5 (00:1e:2a:e7:49:e5)
    Transmitter address: EfmNetwo_fb:7f:08 (00:26:66:fb:7f:08)
    Source address: EfmNetwo_fb:7f:09 (00:26:66:fb:7f:09)
    BSS Id: EfmNetwo_fb:7f:08 (00:26:66:fb:7f:08)
    STA address: Netgear_e7:49:e5 (00:1e:2a:e7:49:e5)
    .... .... .... 0000 = Fragment number: 0
    1001 0010 0011 .... = Sequence number: 2339
    Frame check sequence: 0xe6c5bc10 [correct]
    Qos Control: 0x0000
        .... .... .... 0000 = TID: 0
        [.... .... .... .000 = Priority: Best Effort (Best Effort) (0)]
        .... .... ...0 .... = EOSP: Service period
        .... .... .00. .... = Ack Policy: Normal Ack (0x0000)
        .... .... 0... .... = Payload Type: MSDU                        <---- amsdupresent
        0000 0000 .... .... = QAP PS Buffer State: 0x0000
    CCMP parameters
Data (1416 bytes)
    Data: 61b3110b310325b7fc36bdbdf74b7602fae73599ebb6a787...
    [Length: 1416]

Note in my example this device is in power save mode; in particular, using U-APSD. I suspect this may have some impact, if at the very least to force packets to be queued at the AP so more likely to be aggregated.

I could not see the A-MPDU settings in the HT IE from the client due to the filter on the trace. However, the APs were visible from the probe responses. I note that they are the same manufacturer, but they have different A-MPDU settings. This may be correct according to your configuration, but at the very least, very your configs to make sure they are what you want.

alt text

I also note you are in 40MHz bandwidth with 2.4GHz. Allowed, but very unusual. Many devices won't support it, like Apple and Cisco. Your data rates are high, which is good.

I am not sure if your approach is just to see what is happening or you suspect a problem and are troubleshooting. Though it would be nice to be able to trigger behavior, if your system does not use A-MSDU techniques, they are not likely the cause of the problem.

permanent link

answered 15 Jul '16, 12:10

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

edited 16 Jul '16, 01:11

You need to have a wireless capture system capable of monitor mode and promiscuous mode. Looking at your WiFi adapter, I see three versions, with three different chipsets:


Which one do you have? These span the range from Mediatek - Atheros - Broadcom. They likely all have different characteristics. I have one of these but not with me; I recall mine does monitor mode but not promiscuous mode. You need both modes, and the actual support can change with the system you are running (i.e. Windows Vs. Linux, what kernel, etc).

You will likely be on a Linux platform to do this, but that is an assumption. Windows is non-starter for me on this but you might be able to get the NPCAP driver to work with one of these. NPCAP just causes all my machines to BSOD, so I can't use it.

I can capture A-MSDU frames with just ping, so likely your download method will work too if everything is connected with 802.11n and WMM is enabled. Note that it may be more likely to get aggregated frames if some type of power save is in use; this way, we can ensure that frames are sitting in a buffer for some time so they AP has plenty of opportunity to aggregate them.

You will then just have to try it and see - be sure you are capturing unicast frames, then look for aggregated ones. There is some chance the AP won't do them, or the client you use for testing won't. In this case, keep trying with different APs and clients.

alt text

permanent link

answered 06 Jul '16, 03:32

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

Hi Jones,

Thanks for the answer. Mine is WNDA3100v1 (Atheros). How do I know a WiFi adapter supports both monitor mode and promiscuous mode? I already enable the promiscuous mode in all interface (Capture -> Options -> Enable promiscuous mode in all interfaces). Is that it?

Do I need special router to do the aggregation? Or all routers with 802.11n support should be fine?

I am using Windows 10 at the moment. Do you think I should try using Linux? What version do you recommend? I have Ubuntu Desktop 16.04.

As I see in your screenshot, there is Radiotap header. Mine is showing Ethernet Header. Why is it different? Do you use any add-ons on your Wireshark?

Anyway, I tried again, still using Windows 10, and using built-in WiFi card from my laptop (Lenovo G40-80, Atheros AR956x), when I try to ping (I changed the size to 3000 bytes)

Frame 143: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0

Ethernet II, Src: LiteonTe_xx:xx:xx (xx:xx:xx:xx:xx:xx), Dst: Tp-LinkT_xx:xx:xx (xx:xx:xx:xx:xx:xx)

Internet Protocol Version 4, Src:, Dst:

Internet Control Message Protocol

and inside the 3rd row:

[3 IPv4 Fragments (3008 bytes): #141(1480), #142(1480), #143(48)]

[Frame: 141, payload: 0-1479 (1480 bytes)]

[Frame: 142, payload: 1480-2959 (1480 bytes)]

[Frame: 143, payload: 2960-3007 (48 bytes)]

[Fragment count: 3]

[Reassembled IPv4 length: 3008]

[Reassembled IPv4 data: 0800cfb0000100216162636465666768696a6b6c6d6e6f70...]

(06 Jul '16, 07:56) ajebulon

Ethernet headers are typically provided by drivers set to other than monitor mode, Radiotap headers are provided by drivers set to monitor mode.

At Windows 10, you need to use npcap to be able to use monitor mode of a wireless adapter (and in this case, promiscuous mode should be set automatically with monitor mode). It should be fine with an Atheros chipset but you won't know until you try. And in contrary to what I have stated above, in this particular case, the header will always be a radiotap one, even in non-monitor mode (unless Yang Luo has changed something recently).

(06 Jul '16, 13:16) sindy

After re-reading your OP - if you want to capture at the receiving client's Wi-Fi adaptor, using monitoring mode is out of question at Windows 10 because by running monitoring mode you lose association to the AP (which is not the case at Mac). However, since npcap provides the radiotap header even in promiscuous mode, it might also provide the aggregated frames rather than the spliced ones.

It would be best to first use one of your WiFi adaptors to run the actual communication and using the other one to capture in monitoring mode, to see whether the aggregated frames exist in the air, and then to try the same with capture in promiscuous mode on the adaptor running the actual communication to see whether the promiscuous mode with npcap shows them raw or not.

(06 Jul '16, 13:33) sindy

Thanks for the answer. Mine is WNDA3100v1 (Atheros). How do I know a WiFi adapter supports both monitor mode and promiscuous mode? I already enable the promiscuous mode in all interface (Capture -> Options -> Enable promiscuous mode in all interfaces). Is that it?

No, you also need to enable monitor mode - which, on Windows, is, as sindy has noted, only possible with Windows Vista and later with recent versions of NPcap (it advertises support for Windows 7 and later, but it might also work on Vista).

It would probably work better on Linux, although, currently, you probably can't enabled it using the Wireshark GUI; see the CaptureSetup/WLAN page on the Wireshark Wiki for details on enabling monitor mode on various operating systems.

(06 Jul '16, 13:48) Guy Harris ♦♦

Hi Sindy,

Thanks for the explanation. I already tried to uninstall the winpcap and use npcap instead. However, the header is still using Ethernet header, instead of being always Radiotap header like you mentioned before. Btw, what is the best way to generate aggregated packet? Thanks.

Hi Guy Harris,

I already tried using Ubuntu 16.04 LTS, and I've been able to use the monitoring mode. I am going to try to capture the aggregated packets. Thanks.

(06 Jul '16, 23:14) ajebulon

Thanks for the explanation. I already tried to uninstall the winpcap and use npcap instead. However, the header is still using Ethernet header, instead of being always Radiotap header like you mentioned before.

Unless you capture in monitor mode - which I think currently requires a tool that comes with NPcap; the checkbox might not work yet - you will get Ethernet headers.

(07 Jul '16, 00:30) Guy Harris ♦♦

NPcap is a Work in (rapid) Progress and I haven't kept pace for a couple of weeks. The last time I gave it a try:

  • you had to install it in a special way (or maybe use a special installation package, I don't remember exactly) so that the monitoring mode on wireless cards would be supported, and if you did install that way, you got Radiotap headers even without monitoring mode (for wireless cards only). This was causing some confusion e.g. because the "protected" bit was indicating that the frame data are encrypted but they were actually already decrypted by the adaptor, so you had to tell Wireshark to ignore the protection bit and dissect the payload.

  • a companion command line tool, which was installed too, was necessary to switch the monitor mode on - as @Guy Harris notes, the integration between Wireshark and NPcap in this point is also work in progress.

(07 Jul '16, 03:31) sindy

Hi guys,

I've already been able to capture some packets in monitoring mode, using Ubuntu and follow the Wireshark capture setup. However, I couldn't find any information about aggregated packet, like the one showed in the screenshot from Bob Jones. There is no IEEE 802.11 Aggregate MSDU information.

I generated traffic by downloading file from Google Drive. Was there anything that I did wrong? Or is my router and WiFi adapters not compatible for capturing aggregated packet?


(11 Jul '16, 19:05) ajebulon

Post a trace so we can stop guessing.

I have that version of device and it will do monitor mode but not promiscuous mode on kali rolling with a 4.5 kernel. A trace will verify if you have this issue. If so, you need different capture hardware.

(11 Jul '16, 22:16) Bob Jones

Hello again Bob Jones,

I already uploaded my trace file. It is here.

I ran Wireshark on my Ubuntu PC, which generated traffic by downloading a file from the Internet.

WiFi Adapter: NetGear WNDA3100v1

Router: ipTIME N608

Capture Filter: not broadcast and not multicast

Thank you.

(13 Jul '16, 00:54) ajebulon
showing 5 of 10 show 5 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 05 Jul '16, 22:55

question was seen: 8,533 times

last updated: 16 Jul '16, 01:11

p​o​w​e​r​e​d by O​S​Q​A