From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>,
radiotap <radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org>
Subject: Re: Format of a capture with multiple MPDUs from an A-MPDU?
Date: Tue, 16 Jun 2015 09:06:13 +0200 [thread overview]
Message-ID: <1434438373.2337.5.camel@sipsolutions.net> (raw)
In-Reply-To: <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
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
parent reply other threads:[~2015-06-16 7:06 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7517A666-A4BD-44A5-9E5A-EEED0B55939A-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]
Reply instructions:
You may reply publicly 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1434438373.2337.5.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org \
--cc=guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).