From: David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org"
<radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org>
Subject: Re: Regarding A-MPDU status field
Date: Wed, 9 Nov 2011 14:45:42 -0600 [thread overview]
Message-ID: <20111109204542.GK655@pixotech.com> (raw)
In-Reply-To: <1320847366.3845.72.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On Wed, Nov 09, 2011 at 03:02:46PM +0100, Johannes Berg wrote:
> Hi,
>
> > > -- it might also be helpful to know the padding length before/after
> > (?) the packet for example.
> > We can add
> > 1) Padding length information
> > a) value of padding length after the MPDU, and
> > b) (debatable) total padding length before the subframe for the
> > special case of preceding delimiters with MPDU length zero used to
> > meet minimum MPDU start spacing requirements. All the octets of the
> > preceding 'zero delimiters' together form the pad, as I understand.
> > Note that this information might not be provided by some hardware.
> > If an MPDU (not 'zero delimiter') is actually present prior to the
> > current subframe for which radiotap info is being displayed, 1b)
> > should be zero for the current subframe. Post MPDU pad length
> > information for the prior MPDU would anyway be available (assuming the
> > containing subframe of the prior MPDU is not corrupted).
>
> So what I wanted here was to be able to reconstruct what happened on the
> air as precisely as possible. I don't think the length of the padding is
> actually needed -- it can be calculated after the fact since it is
> always 0-3 bytes up to a multiple of 4. The number of zero delimiters
> would be more interesting.
>
> I'm not sure how to deal with the corruption case.
>
> > Additionally:
> > 2) A bit to indicate if this is the last subframe in the A-MPDU.
> > Though there might be other ways to infer this information, having it
> > as an explicit field would provide convenience.
>
> That seems useful, although I'm not even sure how you would even know
> that it is the last one?
>
> > 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? 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.
>
> > 4) (Debatable) Delimiter CRC value itself. I don't know if there is
> > any hardware which returns the actual value to software. Anyway,
> > having it as part of the field will allow platforms which do possess
> > the capability, to provide this information. It may come in handy for
> > some users.
>
> That seems a bit of a stretch, but it's only 8 bits so I wouldn't mind
> adding it.
I think that in the interest of, as you say, "reconstruct[ing] what
happened on the air as precisely as possible", which is a goal that I
strongly agree with, it is important to pass that information up.
On the other hand, if the information is only hypothetically
available....
Dave
--
David Young
dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981
next prev parent reply other threads:[~2011-11-09 20:45 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 [this message]
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
[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=20111109204542.GK655@pixotech.com \
--to=dyoung-e+axbwqsrlaavxtiumwx3w@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).