RadioTap Archive on
 help / color / Atom feed
From: Johannes Berg <>
To: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/>
Cc: David Young <>,
	radiotap <>
Subject: Re: Format of a capture with multiple MPDUs from an A-MPDU?
Date: Tue, 16 Jun 2015 09:06:13 +0200
Message-ID: <> (raw)
In-Reply-To: <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/>

On Mon, 2015-06-15 at 19:08 -0700, Guy Harris wrote:
> In Wireshark bug 11277:
> somebody complained that a capture containing what I infer was a bunch
> of de-aggregated MPDUs from an A-MPDU wasn't dissected correctly
> because Wireshark didn't assume that the frame data following the
> radiotap header began with an MPDU delimiter of the sort described in
> 8.6.1 "A-MPDU format" in 802.11-2012.
> Is the intent that a de-aggregated MPDU from an A-MPDU begin with a
> delimiter, or not?  If so, the Wireshark dissector needs to be fixed;
> if not, ns3 needs to be fixed.  In either case, the radiotap spec
> should probably indicate what the payload following the radiotap
> header should look like if the radiotap header has the A-MPDU status
> field, to prevent bugs of this sort (whatever sort that might be) from
> showing up in other software.

I certainly didn't intend to have it that way, and we've never generated
(or been able to) such a file in Linux.

The documentation (
20status) also states

"The presence of this field indicates that the frame was received as
part of an a-MPDU."

and I'd say that we meant this to mean that it's a normal frame like any

Additionally, the A-MPDU status information has the ability to include
the delimiter CRC value, so there's no need to include the MPDU
delimiter since it (apart from the reserved bits being potentially set
by a confused transmitter) can be fully reconstructed using just the
length of the frame (known from the pcap - radiotap len or so) and the
CRC value.

I wouldn't even recommend using a reserved bit to indicate "MPDU
delimiter is present" since that will break all radiotap parsers that
are unable to understand that bit, which would be unfortunate. Such
metadata should, IMHO, be added to a radiotap field since the "contents"
of the frames is always assumed to start with an 802.11 header.


           reply index

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/>]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --cc=guy-FrUbXkNCsVf2fBVCVOL8/ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on

Archives are clonable:
	git clone --mirror radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone