RE: Regarding A-MPDU status field

Hi,

>> If space isn’t at a premium, I agree we should make it u32. There
>> might be some embedded system sniffers where this space still matters,
>> since it is multiplied by # of packets – but see discussion a
>> paragraph later.
>Hm, not sure -- yes, it is multiplied, but it's still dwarfed by the
>size of the packets -- this won't help much if your system is disk space
>constrained -- in that case you'll need to get the data out of it as
>soon as possible anyway.
I agree. In any case, we need the extra bytes for 'future-proofing'.

>> I didn’t get which app you are referring to  – Wireshark or the
>> real-time app?
>Sorry, not sure -- either one? Any application that displays things?
You summarized correctly below about the calculations in the illustration I presented. 

>> I was suggesting in my example that the developer of the real-time app
>> would gain knowledge about the padding behavior when experimenting
>> with Wireshark during a study phase. She could then develop the real
>> time app such that it checks the TCP/IP and 802.11 settings to
>> estimate what the MPDU size would be, and then adjusts the # of app
>> payload bytes (fed into the socket) to minimize the subframe-end
>> padding wastage. This would be one among a series of little
>> optimizations (and it wouldn’t work all the time).
>> This is just an illustration.
>> Again, it is independent of the Radiotap field definition.
>Right. I had misunderstood you -- you wanted wireshark to display the
>padding saying it could easily be calculated, and I thought you were
>referring to a calculation wireshark would make, while you were in fact
>referring to a calculation the user of wireshark would make. Sorry :)

>So let me briefly recap what we talked about, is that accurate?
Thanks for summarizing the field definitions. 

> A-MPDU radiotap field
>-----------------------
>bit index: TBD
>alignment: 4 bytes (u32)
>
> * ampdu reference number (u32)
We need to add a note about the reference number being different for every channel.

> * ampdu subframe index (u32) [*1]
> * flags (u8?)
>   - 0x01: driver reports 0-length subframes
>   - 0x02: is 0-length subframe (valid if 0x01 set)
>   - 0x04: last subframe known
>           (should be set for all subframes if driver knows)
>   - 0x08: is last subframe in ampdu (valid if 0x04 set)
>           (clear for all but last subframe)
>   - 0x10: delimiter CRC error
>   - 0x20: delimiter CRC value known
> * delimiter CRC value (u8) (valid if flag 0x20 set)
>
>
>[*1] you said subframe index would be valid if driver reports 0-length
>subframes -- why not a separate bit to indicate this is valid?
The subframe index would always be valid. It would provide the position of the current subframe, in within the A-MPDU (irrespective of whether the subframe is zero or non-zero MPDU length). The index value itself is zero-based (i.e., it starts from 0 and increments onwards).

a) If 0x01 is set, then the index for the current subframe takes into account previous zero MPDU length subframes (because these previous zero subframes have been reported individually and the index incremented for each of them).
b) If 0x01 is clear, then the index for the current subframe does not account for previous zero MPDU length subframes that might have been transmitted over the air.

Thus if two different drivers are observing the same traffic:
The driver that sets 0x01 will report a larger index value for a given non-zero subframe, than the driver that clears 0x01 (if zero padding occurs before that subframe). 

If 0x01 is set, then the sniffer app can calculate zero padding by processing index information and MPDU length field values across subframes.

Everything else looks good.

Regds,
Krishna.