Re: Format of a capture with multiple MPDUs from an A-MPDU?

Johannes Berg <[email protected]> Tue, 16 Jun 2015 09:06:13 +0200
Newsgroups org.netbsd.radiotap
Message-ID <[email protected]>
On Mon, 2015-06-15 at 19:08 -0700, Guy Harris wrote:
> In Wireshark bug 11277:
> 
> 	https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=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 (http://www.radiotap.org/defined-fields/A-MPDU%
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
other.

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.

johannes