From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: "Rao, Krishna" <kcrao-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org"
<radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org>
Subject: RE: Regarding A-MPDU status field
Date: Mon, 21 Nov 2011 10:27:00 +0100 [thread overview]
Message-ID: <1321867620.3999.7.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BC8C00-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
Hi,
> >>>> 3) A bit to indicate if the Delimiter CRC is in error.
> >>>That's useful, but in that case are you even decoding the MPDU and
> >>>passing it up?
> >> In case the delimiter CRC for a subframe containing an MPDU is
> >> corrupted, is it an option to record and display only the radiotap
> >> header without the (suspect) MPDU following it? This will at least let
> >> the user know a subframe corruption has happened. Except the
> >> 'Delimiter CRC error' bit, all other A-MPDU status field contents can
> >> be set as invalid.
> >> If this option is not available, may be we should just drop 3 (and by
> >> extension, 4 'Delimiter CRC Value') to avoid ambiguity.
> >
> >I think we can do that. Or display it but mark it as bad in some way if
> >this happens
> Ok. For hardware that does return the suspect MPDU, we can display it
> - I suggest not as an MPDU, but as a bunch of un-dissected bytes (the
> reason for this suggestion, along with alternatives, will be discussed
> shortly). For hardware that doesn't return the suspect MPDU (or is
> capable, but doesn't under some circumstances), we should have the
> flexibility to display only the Radiotap header.
>
> >(maybe also set the bad FCS bit if that isn't independently
> >calculated anyway?)
> Since the Delimiter CRC only covers the Reserved bits and MPDU length
> field of the subframe (and not the MPDU itself), we wouldn't be sure
> if the MPDU FCS is really bad on the basis of just the Delimiter CRC
> being bad. For that matter, we wouldn't even be sure if what we think
> is the MPDU FCS is actually so (depending on hardware implementations
> and parse recovery failures). This is the reason I suggested
> displaying the MPDU as a bunch of un-dissected bytes.
Right, that makes sense.
> Alternatively, the wireshark implementation can carry out an attempted
> heuristic dissection, with Wireshark documentation updated to warn
> that this can go quite awry.
That might be easier to implement, but ultimately it's up to the
wireshark implementation. Could even be configurable :-)
> >>>Also what if a zero delimiter has a bad CRC? Or what if
> >>>it just got corrupted and you have to recover parsing? I'm not sure
> >>>we can cover all these cases.
> >> Assuming the option discussed above is available:
> >> Perhaps we should limit the scope of all A-MPDU status field
> >> information as being applicable only to subframes actually containing
> >> MPDUs. Even 1b, 'Number of zero delimiters before current subframe'
> >> would be with reference to a given 'non-zero' MPDU bearing subframe.
> >> If we accept the above limitation, then a zero delimiter having a bad
> >> CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will
> >> never be providing this information for any zero delimiter. However,
> >> there is an open question about what happens once hardware recovers
> >> parsing after a corrupted zero delimiter and and successfully gets a
> >> non-zero MPDU bearing subframe. Generally speaking, I feel there is
> >> scope for ambiguity/variances about how differing products can react
> >> and return information used for constructing 1b. In case this is a
> >> concern, we could drop 1b as well.
> >
> >Given that hardware might even implement different strategies for
> >recovering (iirc the spec only has an informational description of an
> >algorithm), I think that's fair. It'd be nicer to have perfectly
> >comparable values, but I wouldn't leave things out just because of that.
>
> >Technically we could also report each zero delimiter as a separate
> >zero-length frame I guess.
> I like this idea. It sounds better than having subfield 1b. We can
> more uniformly handle bad delimiter CRC events.
:)
Did you keep track and want to write up a new proposal?
johannes
next prev parent reply other threads:[~2011-11-21 9:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-31 9:13 Regarding A-MPDU status field Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398BB2E90-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2011-11-02 8:42 ` Johannes Berg
[not found] ` <1320223343.3950.29.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-11-03 15:02 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398BB67FA-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2011-11-09 14:02 ` Johannes Berg
[not found] ` <1320847366.3845.72.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-11-09 20:45 ` David Young
2011-11-13 16:49 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398BBBD18-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2011-11-14 8:26 ` Johannes Berg
[not found] ` <1321259214.4472.16.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-11-20 16:37 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398BC8C00-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2011-11-21 9:27 ` Johannes Berg [this message]
[not found] ` <1321867620.3999.7.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2011-11-22 14:27 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398BC971A-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2011-11-22 17:06 ` David Young
2011-11-22 14:33 ` Rao, Krishna
2011-11-23 15:23 ` Rao, Krishna
2012-01-03 17:25 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398C1F289-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2012-01-04 10:42 ` Johannes Berg
[not found] ` <1325673736.3339.27.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-01-08 13:43 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398C20149-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2012-01-09 10:16 ` Johannes Berg
[not found] ` <1326104166.3451.21.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-01-15 19:14 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398C36652-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2012-01-16 13:46 ` Johannes Berg
[not found] ` <1326721599.3510.18.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-01-23 16:16 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398C3D354-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2012-02-20 11:03 ` Johannes Berg
[not found] ` <1329735809.3458.14.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-02-22 1:14 ` Rao, Krishna
[not found] ` <21E1C3B49A18BA428D58607D5EEA5398C55E21-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
2012-02-23 15:48 ` Johannes Berg
2012-07-05 9:49 ` Johannes Berg
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=1321867620.3999.7.camel@jlt3.sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=kcrao-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org \
--cc=radiotap-sUITvd46vNxg9hUCZPvPmw@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 NNTP newsgroup(s).