RE: Regarding A-MPDU status field

Hi,

> Did you keep track and want to write up a new proposal?

Here is the new proposal based on earlier discussions. This is not yet in standard Radiotap field definition format. This is because there are some subfields which have not been discussed before (or have been updated), and the group may have comments on these. Comments on previously settled subfields too are welcome.

Guiding principle: We attempt to arrive at a field definition which allows drivers/hardware capable of providing advanced information to do so, in the interest of being able to reconstruct whatever happened on the air as precisely as possible. This advanced information covers both success and failure conditions. This could aid in enhanced analysis. Driver/hardware combinations with lesser capability may skip some of the sub-fields - Wireshark will work with whatever is available and provide correspondingly reduced information. 

1) (New) Driver generated A-MPDU reference number (u16). All subframes belonging to the same A-MPDU will have the same reference number (but see rollover condition discussed shortly). This reference number allows the driver to reliably convey to sniffer application which subframes it found under the same A-MPDU, independent of driver data path characteristics, zero MPDU length subframes, mix of traffic on the air, and various error conditions. The reference number is common across all traffic and not maintained separately for separate DA-SA pairs or any such tuples.
Rollover is easily handled by sniffer application using timestamp locality. Subframes with the same reference number which don't actually belong to the same A-MPDU (owing to rollover) will have timestamps several seconds apart.
2) (New) A bit to indicate if the driver is capable of returning information about individual zero MPDU length subframes.
3) (New) A bit to indicate if the current subframe is a zero MPDU length subframe. Valid if bit ‘2’ above is set.
4) (Updated) Index field: Zero-based index of the subframe, within the A-MPDU (u16). This is applicable to zero MPDU length subframes as well, if bit ‘2’ above is set.
5) A bit to indicate if ‘6’ below is valid.
6) A bit to indicate if this is the last subframe in the A-MPDU. This does not apply to zero MPDU length subframes.
7) (Updated) A bit to indicate if the Delimiter CRC is in error. This is applicable to zero MPDU length subframes as well, if bit ‘2’ above is set. If the driver/hardware doesn’t pass upwards subframes for which Delimiter CRC is in error, then this bit should be cleared (i.e. 0) all the time - only successfully parsed subframes will be passed to the sniffer application (note that here, successfully parsed does not necessarily mean that the 802.11 FCS too will be valid – the two are different).
We don’t provide a means to indicate if this bit is ‘invalid’. If a driver doesn’t know whether what it is passing upwards has been successfully parsed or not, IMHO there could be serious implementation mistakes at some level.
8) A bit to indicate if ‘9’ below is valid.
9) Delimiter CRC value itself (8 bits). Applicable only if the Delimiter CRC is in error, i.e. bit 7 is set.

(To accommodate the case where a driver/hardware combination may be capable of providing total zero MPDU based padding length before a given subframe, but not info on individual zero MPDU subframes themselves, should we add one more field which directly gives the total padding length? Bit 2 will be zero in this case. Discussion 1 under ' Wireshark Implementation Suggestions' will get modified). 

Wireshark Implementation Suggestions:

1) If bit 2 is set by driver: Total value of zero MPDU length padding before a given non-zero length MPDU containing subframe should be calculated by Wireshark. If the Delimiter CRC is in error for any of the zero-length MPDU subframes involved, then the padding value should be set to invalid (Question: Can we set this to something like ‘indeterminate’ to differentiate it from the case where bit 2 is 0, described below?)
If bit 2 is 0, then Wireshark should set the padding value to invalid.

2) If Delimiter CRC is in error, then the hardware may or may not return the suspect MPDU bytes.
    a) If h/w does not return MPDU bytes, then Wireshark can display just the Radiotap header without the MPDU contents
    b) If h/w does return the suspect MPDU bytes, Wireshark may carry out one of the following based on configuration settings:
        i) Display the suspect MPDU as a bunch of un-dissected bytes.
        ii) Attempt a heuristic dissection of the MPDU bytes. But note that this can go quite wrong due to uncertainty about validity of MPDU boundaries.
 
3) If Delimiter CRC is not in error, the driver will not copy the CRC value from hardware. Wireshark should calculate the value itself.

4) (Optional) Value of subframe padding length after the MPDU could be calculated and displayed by Wireshark. Though this can be easily calculated from MPDU length, it is good to help users easily observe and filter on this value without having to resort to any post processing scripts. If the value is readily observable, it might help for example, a mobile app developer with only cursory knowledge of 802.11n to chance upon and inquire into the reason for the padding. For real-time apps operating in noisy RF environments, adjusting the payload bytes to minimize subframe padding may form one of many little optimizations  to extract better performance (depending on traffic characteristics).

Regards,
Krishna