How to Capture Aggregated Packets (A-MPDU / A-MSDU) using Wireshark

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:

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:

8.2.4.5.9 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 8.3.2.2. 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 8.3.2.1.

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.

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.

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:

1. https://wikidevi.com/wiki/Netgear_WNDA3100v3
2. https://wikidevi.com/wiki/Netgear_WNDA3100v2
3. https://wikidevi.com/wiki/Netgear_WNDA3100v1

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.