RE: Regarding A-MPDU status field

Hi,

>>>>> 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....
>> Since there is always a possibility that some existing or future
>> hardware might have this capability, having this subfield in the
>> specification might prove useful down the line. Inviting comments on
>> this.
>
>Still thinking along the lines of "reconstruct ... as precisely", let me
>throw this idea out there: the A-MPDU field can help us to reconstruct a
>whole A-MPDU by telling us the range of byte indices where the subframe
>may have begun in the aggregate, [start0, start1].
I feel the originally suggested subfield, 'zero-based index of this MPDU within the a-MPDU', in combination with the (shortened list of) new subfields being discussed should help achieve the equivalent. The Wireshark implementation should be able to estimate these indices based on information returned in the individual A-MPDU fields for 'non-zero' and 'zero' subframes.

>If the driver
>doesn't know, then the interval is [0, length of A-MPDU].  If the driver
>knows precisely, then [x, x], otherwise [x, y] where x != y.
Along the same line of trying to reconstruct things as precisely as possible, we should be able to reconstruct what went wrong:
If the driver doesn't know (info towards) the indices precisely, then the reason would mostly be corruption of Delimiter CRC protecting MPDU length info in subframe. I feel the Radiotap standard should afford the driver the opportunity to convey what went wrong on the air, depending on hardware capabilities (Delimiter CRC is bad, what the bad CRC value itself is, and any suspect bytes found by hardware where the MPDU should have been).

Regards,
Krishna