RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* Re: Format of a capture with multiple MPDUs from an A-MPDU?
       [not found] ` <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
@ 2015-06-16  7:06   ` Johannes Berg
  0 siblings, 0 replies; only message in thread
From: Johannes Berg @ 2015-06-16  7:06 UTC (permalink / raw)
  To: Guy Harris; +Cc: David Young, radiotap

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, back to index

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <7517A666-A4BD-44A5-9E5A-EEED0B55939A@alum.mit.edu>
     [not found] ` <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-06-16  7:06   ` Format of a capture with multiple MPDUs from an A-MPDU? Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 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/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git