From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: Regarding A-MPDU status field Date: Mon, 31 Oct 2011 09:13:24 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_21E1C3B49A18BA428D58607D5EEA5398BB2E90nasanexd02bnaqual_" Return-path: Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org --_000_21E1C3B49A18BA428D58607D5EEA5398BB2E90nasanexd02bnaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, I noticed that the A-MPDU status field has been listed under 'Suggested Fie= lds' (http://www.radiotap.org/suggested-fields). I feel having this field w= ill make things easier in some scenarios, especially when carrying out perf= ormance related analysis. I would like to request for this field to be made official. (In case I am missing any context, do let me know. I did briefly check the = mailing list, but something might have slipped by). Regards, Krishna Rao, Sr. Lead Engineer, Qualcomm Atheros Inc. --_000_21E1C3B49A18BA428D58607D5EEA5398BB2E90nasanexd02bnaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

I noticed that the A-MPDU status field has been list= ed under ‘Suggested Fields’ (http://www.radiotap.org/suggested-fields). I feel ha= ving this field will make things easier in some scenarios, especially when carrying out performance related analysis.=

 

I would like to request for this field to be made of= ficial.

 

(In case I am missing any context, do let me know. I= did briefly check the mailing list, but something might have slipped by).<= o:p>

 

Regards,

Krishna Rao,

Sr. Lead Engineer,

Qualcomm Atheros Inc.

 

 

--_000_21E1C3B49A18BA428D58607D5EEA5398BB2E90nasanexd02bnaqual_-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: Regarding A-MPDU status field Date: Wed, 02 Nov 2011 09:42:23 +0100 Message-ID: <1320223343.3950.29.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BB2E90-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org [please try writing text-only email] > I noticed that the A-MPDU status field has been listed under > =E2=80=98Suggested Fields=E2=80=99 (http://www.radiotap.org/suggested-f= ields). I feel > having this field will make things easier in some scenarios, > especially when carrying out performance related analysis. Indeed. > I would like to request for this field to be made official.=20 I had worked on this for a while, but never followed through on the process of formally adopting it. Having a driver that supports this field would also be required so we can judge its implementation, and so far I haven't had a chance to add support to any driver. If you can do that for any of the QCA drivers that would be helpful. Also, the question about the contents came up at some points -- it might also be helpful to know the padding length before/after (?) the packet for example. johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Thu, 3 Nov 2011 15:02:09 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1320223343.3950.29.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj5IYXZpbmcgYSBkcml2ZXIgdGhhdCBzdXBwb3J0cyB0aGlzIGZpZWxkIHdvdWxkIGFs c28gYmUgcmVxdWlyZWQgc28gd2UgY2FuIGp1ZGdlIGl0cyBpbXBsZW1lbnRhdGlvbiwNCj5hbmQg c28gZmFyIEkgaGF2ZW4ndCBoYWQgYSBjaGFuY2UgdG8gYWRkIHN1cHBvcnQgdG8gYW55IGRyaXZl ci4gSWYgeW91IGNhbiBkbyB0aGF0IGZvciBhbnkgb2YgdGhlIFFDQQ0KPmRyaXZlcnMgdGhhdCB3 b3VsZCBiZSBoZWxwZnVsLg0KT25jZSB3ZSBzZXR0bGUgdXBvbiB0aGUgYWRkaXRpb25hbCBjb250 ZW50IChkaXNjdXNzZWQgYmVsb3cpLCBJJ2xsIHNlZSBpZiBJIGNhbiBnZXQgc29tZW9uZSB0byB0 cnkgdGhpcyBvdXQgb24gYXRoOWsuIEVsc2UsIEkgd291bGQgbG92ZSB0byBhZGQgdGhlIHN1cHBv cnQgbXlzZWxmIGR1cmluZyBvbmUgb2YgdGhlIGNvbWluZyB3ZWVrZW5kcyB3aGVuIEkgZ2V0IHNw YXJlIHRpbWUuDQoNCj5BbHNvLCB0aGUgcXVlc3Rpb24gYWJvdXQgdGhlIGNvbnRlbnRzIGNhbWUg dXAgYXQgc29tZSBwb2ludHMgDQpJIGFncmVlIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIGRp c2N1c3MgYWRkaXRpb25hbCBjb250ZW50cyBiZWZvcmUgZmluYWxpemluZyB0aGUgZmllbGQuIEkn bGwgcHJlc2VudCBzb21lIHN1Z2dlc3Rpb25zIHRvIHJlc3RhcnQgdGhlIGRpc2N1c3Npb24uIFJl cXVlc3RpbmcgZmVlZGJhY2sgZnJvbSB0aGUgZ3JvdXAuDQoNCj4gLS0gaXQgbWlnaHQgYWxzbyBi ZSBoZWxwZnVsIHRvIGtub3cgdGhlIHBhZGRpbmcgbGVuZ3RoIGJlZm9yZS9hZnRlciAoPykgdGhl IHBhY2tldCBmb3IgZXhhbXBsZS4NCldlIGNhbiBhZGQNCjEpIFBhZGRpbmcgbGVuZ3RoIGluZm9y bWF0aW9uDQphKSB2YWx1ZSBvZiBwYWRkaW5nIGxlbmd0aCBhZnRlciB0aGUgTVBEVSwgYW5kDQpi KSAoZGViYXRhYmxlKSB0b3RhbCBwYWRkaW5nIGxlbmd0aCBiZWZvcmUgdGhlIHN1YmZyYW1lIGZv ciB0aGUgc3BlY2lhbCBjYXNlIG9mIHByZWNlZGluZyBkZWxpbWl0ZXJzIHdpdGggTVBEVSBsZW5n dGggemVybyB1c2VkIHRvIG1lZXQgbWluaW11bSBNUERVIHN0YXJ0IHNwYWNpbmcgcmVxdWlyZW1l bnRzLiBBbGwgdGhlIG9jdGV0cyBvZiB0aGUgcHJlY2VkaW5nICd6ZXJvIGRlbGltaXRlcnMnIHRv Z2V0aGVyIGZvcm0gdGhlIHBhZCwgYXMgSSB1bmRlcnN0YW5kLiBOb3RlIHRoYXQgdGhpcyBpbmZv cm1hdGlvbiBtaWdodCBub3QgYmUgcHJvdmlkZWQgYnkgc29tZSBoYXJkd2FyZS4NCklmIGFuIE1Q RFUgKG5vdCAnemVybyBkZWxpbWl0ZXInKSBpcyBhY3R1YWxseSBwcmVzZW50IHByaW9yIHRvIHRo ZSBjdXJyZW50IHN1YmZyYW1lIGZvciB3aGljaCByYWRpb3RhcCBpbmZvIGlzIGJlaW5nIGRpc3Bs YXllZCwgMWIpIHNob3VsZCBiZSB6ZXJvIGZvciB0aGUgY3VycmVudCBzdWJmcmFtZS4gUG9zdCBN UERVIHBhZCBsZW5ndGggaW5mb3JtYXRpb24gZm9yIHRoZSBwcmlvciBNUERVIHdvdWxkIGFueXdh eSBiZSBhdmFpbGFibGUgKGFzc3VtaW5nIHRoZSBjb250YWluaW5nIHN1YmZyYW1lIG9mIHRoZSBw cmlvciBNUERVIGlzIG5vdCBjb3JydXB0ZWQpLg0KDQpBZGRpdGlvbmFsbHk6DQoyKSBBIGJpdCB0 byBpbmRpY2F0ZSBpZiB0aGlzIGlzIHRoZSBsYXN0IHN1YmZyYW1lIGluIHRoZSBBLU1QRFUuIFRo b3VnaCB0aGVyZSBtaWdodCBiZSBvdGhlciB3YXlzIHRvIGluZmVyIHRoaXMgaW5mb3JtYXRpb24s IGhhdmluZyBpdCBhcyBhbiBleHBsaWNpdCBmaWVsZCB3b3VsZCBwcm92aWRlIGNvbnZlbmllbmNl LiANCjMpIEEgYml0IHRvIGluZGljYXRlIGlmIHRoZSBEZWxpbWl0ZXIgQ1JDIGlzIGluIGVycm9y Lg0KNCkgKERlYmF0YWJsZSkgRGVsaW1pdGVyIENSQyB2YWx1ZSBpdHNlbGYuIEkgZG9uJ3Qga25v dyBpZiB0aGVyZSBpcyBhbnkgaGFyZHdhcmUgd2hpY2ggcmV0dXJucyB0aGUgYWN0dWFsIHZhbHVl IHRvIHNvZnR3YXJlLiBBbnl3YXksIGhhdmluZyBpdCBhcyBwYXJ0IG9mIHRoZSBmaWVsZCB3aWxs IGFsbG93IHBsYXRmb3JtcyB3aGljaCBkbyBwb3NzZXNzIHRoZSBjYXBhYmlsaXR5LCB0byBwcm92 aWRlIHRoaXMgaW5mb3JtYXRpb24uIEl0IG1heSBjb21lIGluIGhhbmR5IGZvciBzb21lIHVzZXJz Lg0KDQpGb3IgYWxsIHRoZSBhYm92ZSBmaWVsZHMsIHRoZXJlIHNob3VsZCBiZSBjb3JyZXNwb25k aW5nIGJpdHMgdG8gaW5kaWNhdGUgaWYgdGhlIHZhbHVlIGlzIHZhbGlkLg0KDQpSZWdkcywNCkty aXNobmEgUmFvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBC ZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDAyLCAyMDExIDI6MTIgUE0NClRvOiBSYW8sIEtyaXNobmENCkNjOiByYWRpb3Rh cEByYWRpb3RhcC5vcmcNClN1YmplY3Q6IFJlOiBSZWdhcmRpbmcgQS1NUERVIHN0YXR1cyBmaWVs ZA0KDQpbcGxlYXNlIHRyeSB3cml0aW5nIHRleHQtb25seSBlbWFpbF0NCg0KPiBJIG5vdGljZWQg dGhhdCB0aGUgQS1NUERVIHN0YXR1cyBmaWVsZCBoYXMgYmVlbiBsaXN0ZWQgdW5kZXIgDQo+IOKA mFN1Z2dlc3RlZCBGaWVsZHPigJkgKGh0dHA6Ly93d3cucmFkaW90YXAub3JnL3N1Z2dlc3RlZC1m aWVsZHMpLiBJIGZlZWwgDQo+IGhhdmluZyB0aGlzIGZpZWxkIHdpbGwgbWFrZSB0aGluZ3MgZWFz aWVyIGluIHNvbWUgc2NlbmFyaW9zLCANCj4gZXNwZWNpYWxseSB3aGVuIGNhcnJ5aW5nIG91dCBw ZXJmb3JtYW5jZSByZWxhdGVkIGFuYWx5c2lzLg0KDQpJbmRlZWQuDQoNCj4gSSB3b3VsZCBsaWtl IHRvIHJlcXVlc3QgZm9yIHRoaXMgZmllbGQgdG8gYmUgbWFkZSBvZmZpY2lhbC4gDQoNCkkgaGFk IHdvcmtlZCBvbiB0aGlzIGZvciBhIHdoaWxlLCBidXQgbmV2ZXIgZm9sbG93ZWQgdGhyb3VnaCBv biB0aGUgcHJvY2VzcyBvZiBmb3JtYWxseSBhZG9wdGluZyBpdC4NCg0KSGF2aW5nIGEgZHJpdmVy IHRoYXQgc3VwcG9ydHMgdGhpcyBmaWVsZCB3b3VsZCBhbHNvIGJlIHJlcXVpcmVkIHNvIHdlIGNh biBqdWRnZSBpdHMgaW1wbGVtZW50YXRpb24sIGFuZCBzbyBmYXIgSSBoYXZlbid0IGhhZCBhIGNo YW5jZSB0byBhZGQgc3VwcG9ydCB0byBhbnkgZHJpdmVyLiBJZiB5b3UgY2FuIGRvIHRoYXQgZm9y IGFueSBvZiB0aGUgUUNBIGRyaXZlcnMgdGhhdCB3b3VsZCBiZSBoZWxwZnVsLg0KDQpBbHNvLCB0 aGUgcXVlc3Rpb24gYWJvdXQgdGhlIGNvbnRlbnRzIGNhbWUgdXAgYXQgc29tZSBwb2ludHMgLS0g aXQgbWlnaHQgYWxzbyBiZSBoZWxwZnVsIHRvIGtub3cgdGhlIHBhZGRpbmcgbGVuZ3RoIGJlZm9y ZS9hZnRlciAoPykgdGhlIHBhY2tldCBmb3IgZXhhbXBsZS4NCg0Kam9oYW5uZXMNCg0KDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Wed, 09 Nov 2011 15:02:46 +0100 Message-ID: <1320847366.3845.72.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BB67FA-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org 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. johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Young Subject: Re: Regarding A-MPDU status field Date: Wed, 9 Nov 2011 14:45:42 -0600 Message-ID: <20111109204542.GK655@pixotech.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> <1320847366.3845.72.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1320847366.3845.72.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Sun, 13 Nov 2011 16:49:56 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com>,<1320847366.3845.72.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1320847366.3845.72.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi,=0A= =0A= >I don't think the length of the padding is=0A= >actually needed -- it can be calculated after the fact since it is=0A= >always 0-3 bytes up to a multiple of 4.=0A= The objective behind suggesting its inclusion was to help users easily obse= rve and filter on this value without having to resort to any post processin= g 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 perfor= mance (depending on traffic characteristics). In the absence of an explicit= ly viewable field, the possibility might not occur to some users.=0A= However, in case the design philosophy behind radiotap is to store only non= -deducible information, I agree we should stick to that. May be Wireshark d= issector code can independently calculate and display this info instead? (A= m yet to get familiar with the code internals, especially with regard to ho= w filtering is impacted by this).=0A= =0A= >The number of zero delimiters=0A= >would be more interesting.=0A= I agree. Also (as implicit in your reply) instead of providing the number o= f bytes, it can simply be the number of delimiters.=0A= But the second part of the discussion below for point 3) 'Delimiter CRC' op= ens up a new question as to whether we should have this subfield at all.=0A= =0A= >I'm not sure how to deal with the corruption case.=0A= See discussion below for point 3) 'Delimiter CRC'=0A= =0A= >> 2) A bit to indicate if this is the last subframe in the A-MPDU.=0A= >> Though there might be other ways to infer this information, having it=0A= >> as an explicit field would provide convenience.=0A= >That seems useful, although I'm not even sure how you would even know=0A= >that it is the last one?=0A= It is possible for hardware to detect this and provide this information to = the driver (am making a generic technical statement without referring to sp= ecific products here). For products not having this capability, this subfie= ld can be marked as invalid (if the driver has no other way to infer the in= formation).=0A= =0A= >> 3) A bit to indicate if the Delimiter CRC is in error.=0A= >That's useful, but in that case are you even decoding the MPDU and=0A= >passing it up?=0A= In case the delimiter CRC for a subframe containing an MPDU is corrupted, i= s 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.=0A= If this option is not available, may be we should just drop 3 (and by exten= sion, 4 'Delimiter CRC Value') to avoid ambiguity.=0A= =0A= >Also what if a zero delimiter has a bad CRC? Or what if=0A= >it just got corrupted and you have to recover parsing? I'm not sure we=0A= >can cover all these cases.=0A= Assuming the option discussed above is available:=0A= Perhaps we should limit the scope of all A-MPDU status field information as= being applicable only to subframes actually containing MPDUs. Even 1b, 'Nu= mber of zero delimiters before current subframe' would be with reference to= a given 'non-zero' MPDU bearing subframe. =0A= If we accept the above limitation, then a zero delimiter having a bad CRC d= oesn't matter for subfield 3) 'Delimiter CRC error'. We will never be provi= ding this information for any zero delimiter. However, there is an open que= stion about what happens once hardware recovers parsing after a corrupted z= ero delimiter and and successfully gets a non-zero MPDU bearing subframe. G= enerally speaking, I feel there is scope for ambiguity/variances about how = differing products can react and return information used for constructing 1= b. In case this is a concern, we could drop 1b as well. =0A= =0A= Regards,=0A= Krishna=0A= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Mon, 14 Nov 2011 09:26:54 +0100 Message-ID: <1321259214.4472.16.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BBBD18-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi, > >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 objective behind suggesting its inclusion was 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). In the absence of an explicitly viewable field, the > possibility might not occur to some users. > However, in case the design philosophy behind radiotap is to store > only non-deducible information, I agree we should stick to that. May > be Wireshark dissector code can independently calculate and display > this info instead? (Am yet to get familiar with the code internals, > especially with regard to how filtering is impacted by this). I can't really say if that's the design philosophy (some things make me think it's not, like the strange channel type field), but it'd certainly be trivial to show it in wireshark either way so personally I think we should leave it out. > >The number of zero delimiters > >would be more interesting. > I agree. Also (as implicit in your reply) instead of providing the > number of bytes, it can simply be the number of delimiters. > But the second part of the discussion below for point 3) 'Delimiter > CRC' opens up a new question as to whether we should have this > subfield at all. Well, ok, so I don't really care about bytes vs. delimiters, I didn't put it that way to mean I'd prefer the number of delimiters. > >> 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? > It is possible for hardware to detect this and provide this > information to the driver (am making a generic technical statement > without referring to specific products here). For products not having > this capability, this subfield can be marked as invalid (if the driver > has no other way to infer the information). Ok, that sounds good. Let's just include it then, it's only a bit after all. > >> 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 (maybe also set the bad FCS bit if that isn't independently calculated anyway?) > >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. johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Sun, 20 Nov 2011 16:37:25 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com>,<1321259214.4472.16.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1321259214.4472.16.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi,=0A= =0A= I apologize for the delay in responding. Was held up with some other work.= =0A= =0A= >>>I don't think the length of the padding is=0A= >>>actually needed -- it can be calculated after the fact since it is=0A= >>>always 0-3 bytes up to a multiple of 4.=0A= >=0A= >> The objective behind suggesting its inclusion was to help users easily= =0A= >> observe and filter on this value without having to resort to any post=0A= >> processing scripts.=0A= [cut]=0A= >> However, in case the design philosophy behind radiotap is to store=0A= >> only non-deducible information, I agree we should stick to that. May=0A= >> be Wireshark dissector code can independently calculate and display=0A= >> this info instead? (Am yet to get familiar with the code internals,=0A= >> especially with regard to how filtering is impacted by this).=0A= >=0A= >I can't really say if that's the design philosophy (some things make me=0A= >think it's not, like the strange channel type field), but it'd certainly= =0A= >be trivial to show it in wireshark either way so personally I think we=0A= >should leave it out.=0A= I agree we can leave it out of the A-MPDU status field itself then.=0A= =0A= >>>> 3) A bit to indicate if the Delimiter CRC is in error.=0A= >>>That's useful, but in that case are you even decoding the MPDU and=0A= >>>passing it up?=0A= >> In case the delimiter CRC for a subframe containing an MPDU is=0A= >> corrupted, is it an option to record and display only the radiotap=0A= >> header without the (suspect) MPDU following it? This will at least let= =0A= >> the user know a subframe corruption has happened. Except the=0A= >> 'Delimiter CRC error' bit, all other A-MPDU status field contents can=0A= >> be set as invalid.=0A= >> If this option is not available, may be we should just drop 3 (and by=0A= >> extension, 4 'Delimiter CRC Value') to avoid ambiguity.=0A= >=0A= >I think we can do that. Or display it but mark it as bad in some way if=0A= >this happens=0A= Ok. For hardware that does return the suspect MPDU, we can display it - I s= uggest 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 u= nder some circumstances), we should have the flexibility to display only th= e Radiotap header.=0A= =0A= >(maybe also set the bad FCS bit if that isn't independently=0A= >calculated anyway?)=0A= 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 th= at matter, we wouldn't even be sure if what we think is the MPDU FCS is act= ually so (depending on hardware implementations and parse recovery failures= ). This is the reason I suggested displaying the MPDU as a bunch of un-diss= ected bytes. =0A= Alternatively, the wireshark implementation can carry out an attempted heur= istic dissection, with Wireshark documentation updated to warn that this ca= n go quite awry.=0A= =0A= >>>Also what if a zero delimiter has a bad CRC? Or what if=0A= >>>it just got corrupted and you have to recover parsing? I'm not sure=0A= >>>we can cover all these cases.=0A= >> Assuming the option discussed above is available:=0A= >> Perhaps we should limit the scope of all A-MPDU status field=0A= >> information as being applicable only to subframes actually containing=0A= >> MPDUs. Even 1b, 'Number of zero delimiters before current subframe'=0A= >> would be with reference to a given 'non-zero' MPDU bearing subframe. =0A= >> If we accept the above limitation, then a zero delimiter having a bad=0A= >> CRC doesn't matter for subfield 3) 'Delimiter CRC error'. We will=0A= >> never be providing this information for any zero delimiter. However,=0A= >> there is an open question about what happens once hardware recovers=0A= >> parsing after a corrupted zero delimiter and and successfully gets a=0A= >> non-zero MPDU bearing subframe. Generally speaking, I feel there is=0A= >> scope for ambiguity/variances about how differing products can react=0A= >> and return information used for constructing 1b. In case this is a=0A= >> concern, we could drop 1b as well. =0A= >=0A= >Given that hardware might even implement different strategies for=0A= >recovering (iirc the spec only has an informational description of an=0A= >algorithm), I think that's fair. It'd be nicer to have perfectly=0A= >comparable values, but I wouldn't leave things out just because of that.= =0A= =0A= >Technically we could also report each zero delimiter as a separate=0A= >zero-length frame I guess.=0A= I like this idea. It sounds better than having subfield 1b. We can more uni= formly handle bad delimiter CRC events.=0A= =0A= Regards,=0A= Krishna =0A= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Mon, 21 Nov 2011 10:27:00 +0100 Message-ID: <1321867620.3999.7.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BC8C00-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Young Subject: Re: Regarding A-MPDU status field Date: Tue, 22 Nov 2011 11:06:05 -0600 Message-ID: <20111122170605.GJ20624@pixotech.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> <1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> <1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC971A@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BC971A-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org On Tue, Nov 22, 2011 at 02:27:17PM +0000, Rao, Krishna wrote: > 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]. 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. Dave -- David Young dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Tue, 22 Nov 2011 14:33:44 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BC9738@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1321867620.3999.7.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj5EaWQgeW91IGtlZXAgdHJhY2sgYW5kIHdhbnQgdG8gd3JpdGUgdXAgYSBuZXcgcHJv cG9zYWw/DQpTdXJlLiBJ4oCZbGwgc2VuZCBpbiBhIHJldmlzZWQgcHJvcG9zYWwuIEhvd2V2ZXIs IEkgcmVhbGl6ZWQgdGhhdCA0IOKAmERlbGltaXRlciBDUkMgdmFsdWUgaXRzZWxm4oCZIGlzIHN0 aWxsIGFuIG9wZW4gaXRlbS4gSSBqdXN0IHNlbnQgb3V0IGEgc2VwYXJhdGUgZW1haWwgdG8gRGF2 aWQgYW5kIHRoZSByZXN0IG9mIHRoZSBncm91cCB0byBkaXNjdXNzIHRoaXMuDQoNClJlZ2FyZHMs DQpLcmlzaG5hDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Tue, 22 Nov 2011 14:27:17 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BC971A@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1321867620.3999.7.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj4+PiA0KSAoRGViYXRhYmxlKSBEZWxpbWl0ZXIgQ1JDIHZhbHVlIGl0c2VsZi4gSSBk b24ndCBrbm93IGlmIHRoZXJlIGlzDQo+Pj4gYW55IGhhcmR3YXJlIHdoaWNoIHJldHVybnMgdGhl IGFjdHVhbCB2YWx1ZSB0byBzb2Z0d2FyZS4gQW55d2F5LA0KPj4+IGhhdmluZyBpdCBhcyBwYXJ0 IG9mIHRoZSBmaWVsZCB3aWxsIGFsbG93IHBsYXRmb3JtcyB3aGljaCBkbyBwb3NzZXNzDQo+Pj4g dGhlIGNhcGFiaWxpdHksIHRvIHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbi4gSXQgbWF5IGNvbWUg aW4gaGFuZHkgZm9yDQo+Pj4gc29tZSB1c2Vycy4NCj4+IA0KPj4gVGhhdCBzZWVtcyBhIGJpdCBv ZiBhIHN0cmV0Y2gsIGJ1dCBpdCdzIG9ubHkgOCBiaXRzIHNvIEkgd291bGRuJ3QgbWluZA0KPj4g YWRkaW5nIGl0Lg0KPg0KPkkgdGhpbmsgdGhhdCBpbiB0aGUgaW50ZXJlc3Qgb2YsIGFzIHlvdSBz YXksICJyZWNvbnN0cnVjdFtpbmddIHdoYXQNCj5oYXBwZW5lZCBvbiB0aGUgYWlyIGFzIHByZWNp c2VseSBhcyBwb3NzaWJsZSIsIHdoaWNoIGlzIGEgZ29hbCB0aGF0IEkNCj5zdHJvbmdseSBhZ3Jl ZSB3aXRoLCBpdCBpcyBpbXBvcnRhbnQgdG8gcGFzcyB0aGF0IGluZm9ybWF0aW9uIHVwLg0KPg0K Pk9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgaW5mb3JtYXRpb24gaXMgb25seSBoeXBvdGhldGlj YWxseQ0KPmF2YWlsYWJsZS4uLi4NClNpbmNlIHRoZXJlIGlzIGFsd2F5cyBhIHBvc3NpYmlsaXR5 IHRoYXQgc29tZSBleGlzdGluZyBvciBmdXR1cmUgaGFyZHdhcmUgbWlnaHQgaGF2ZSB0aGlzIGNh cGFiaWxpdHksIGhhdmluZyB0aGlzIHN1YmZpZWxkIGluIHRoZSBzcGVjaWZpY2F0aW9uIG1pZ2h0 IHByb3ZlIHVzZWZ1bCBkb3duIHRoZSBsaW5lLiBJbnZpdGluZyBjb21tZW50cyBvbiB0aGlzLg0K DQpSZWdhcmRzLA0KS3Jpc2huYQ0K From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Wed, 23 Nov 2011 15:23:49 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398BCBE63@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj4+Pj4+IDQpIChEZWJhdGFibGUpIERlbGltaXRlciBDUkMgdmFsdWUgaXRzZWxmLiBJ IGRvbid0IGtub3cgaWYgdGhlcmUgaXMNCj4+Pj4+IGFueSBoYXJkd2FyZSB3aGljaCByZXR1cm5z IHRoZSBhY3R1YWwgdmFsdWUgdG8gc29mdHdhcmUuIEFueXdheSwNCj4+Pj4+IGhhdmluZyBpdCBh cyBwYXJ0IG9mIHRoZSBmaWVsZCB3aWxsIGFsbG93IHBsYXRmb3JtcyB3aGljaCBkbyBwb3NzZXNz DQo+Pj4+PiB0aGUgY2FwYWJpbGl0eSwgdG8gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uLiBJdCBt YXkgY29tZSBpbiBoYW5keSBmb3INCj4+Pj4+IHNvbWUgdXNlcnMuDQo+Pj4+IA0KPj4+PiBUaGF0 IHNlZW1zIGEgYml0IG9mIGEgc3RyZXRjaCwgYnV0IGl0J3Mgb25seSA4IGJpdHMgc28gSSB3b3Vs ZG4ndCBtaW5kDQo+Pj4+IGFkZGluZyBpdC4NCj4+Pg0KPj4+SSB0aGluayB0aGF0IGluIHRoZSBp bnRlcmVzdCBvZiwgYXMgeW91IHNheSwgInJlY29uc3RydWN0W2luZ10gd2hhdA0KPj4+aGFwcGVu ZWQgb24gdGhlIGFpciBhcyBwcmVjaXNlbHkgYXMgcG9zc2libGUiLCB3aGljaCBpcyBhIGdvYWwg dGhhdCBJDQo+Pj5zdHJvbmdseSBhZ3JlZSB3aXRoLCBpdCBpcyBpbXBvcnRhbnQgdG8gcGFzcyB0 aGF0IGluZm9ybWF0aW9uIHVwLg0KPj4+DQo+Pj5PbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIGlu Zm9ybWF0aW9uIGlzIG9ubHkgaHlwb3RoZXRpY2FsbHkNCj4+PmF2YWlsYWJsZS4uLi4NCj4+IFNp bmNlIHRoZXJlIGlzIGFsd2F5cyBhIHBvc3NpYmlsaXR5IHRoYXQgc29tZSBleGlzdGluZyBvciBm dXR1cmUNCj4+IGhhcmR3YXJlIG1pZ2h0IGhhdmUgdGhpcyBjYXBhYmlsaXR5LCBoYXZpbmcgdGhp cyBzdWJmaWVsZCBpbiB0aGUNCj4+IHNwZWNpZmljYXRpb24gbWlnaHQgcHJvdmUgdXNlZnVsIGRv d24gdGhlIGxpbmUuIEludml0aW5nIGNvbW1lbnRzIG9uDQo+PiB0aGlzLg0KPg0KPlN0aWxsIHRo aW5raW5nIGFsb25nIHRoZSBsaW5lcyBvZiAicmVjb25zdHJ1Y3QgLi4uIGFzIHByZWNpc2VseSIs IGxldCBtZQ0KPnRocm93IHRoaXMgaWRlYSBvdXQgdGhlcmU6IHRoZSBBLU1QRFUgZmllbGQgY2Fu IGhlbHAgdXMgdG8gcmVjb25zdHJ1Y3QgYQ0KPndob2xlIEEtTVBEVSBieSB0ZWxsaW5nIHVzIHRo ZSByYW5nZSBvZiBieXRlIGluZGljZXMgd2hlcmUgdGhlIHN1YmZyYW1lDQo+bWF5IGhhdmUgYmVn dW4gaW4gdGhlIGFnZ3JlZ2F0ZSwgW3N0YXJ0MCwgc3RhcnQxXS4NCkkgZmVlbCB0aGUgb3JpZ2lu YWxseSBzdWdnZXN0ZWQgc3ViZmllbGQsICd6ZXJvLWJhc2VkIGluZGV4IG9mIHRoaXMgTVBEVSB3 aXRoaW4gdGhlIGEtTVBEVScsIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIChzaG9ydGVuZWQgbGlz dCBvZikgbmV3IHN1YmZpZWxkcyBiZWluZyBkaXNjdXNzZWQgc2hvdWxkIGhlbHAgYWNoaWV2ZSB0 aGUgZXF1aXZhbGVudC4gVGhlIFdpcmVzaGFyayBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgYWJs ZSB0byBlc3RpbWF0ZSB0aGVzZSBpbmRpY2VzIGJhc2VkIG9uIGluZm9ybWF0aW9uIHJldHVybmVk IGluIHRoZSBpbmRpdmlkdWFsIEEtTVBEVSBmaWVsZHMgZm9yICdub24temVybycgYW5kICd6ZXJv JyBzdWJmcmFtZXMuDQoNCj5JZiB0aGUgZHJpdmVyDQo+ZG9lc24ndCBrbm93LCB0aGVuIHRoZSBp bnRlcnZhbCBpcyBbMCwgbGVuZ3RoIG9mIEEtTVBEVV0uICBJZiB0aGUgZHJpdmVyDQo+a25vd3Mg cHJlY2lzZWx5LCB0aGVuIFt4LCB4XSwgb3RoZXJ3aXNlIFt4LCB5XSB3aGVyZSB4ICE9IHkuDQpB bG9uZyB0aGUgc2FtZSBsaW5lIG9mIHRyeWluZyB0byByZWNvbnN0cnVjdCB0aGluZ3MgYXMgcHJl Y2lzZWx5IGFzIHBvc3NpYmxlLCB3ZSBzaG91bGQgYmUgYWJsZSB0byByZWNvbnN0cnVjdCB3aGF0 IHdlbnQgd3Jvbmc6DQpJZiB0aGUgZHJpdmVyIGRvZXNuJ3Qga25vdyAoaW5mbyB0b3dhcmRzKSB0 aGUgaW5kaWNlcyBwcmVjaXNlbHksIHRoZW4gdGhlIHJlYXNvbiB3b3VsZCBtb3N0bHkgYmUgY29y cnVwdGlvbiBvZiBEZWxpbWl0ZXIgQ1JDIHByb3RlY3RpbmcgTVBEVSBsZW5ndGggaW5mbyBpbiBz dWJmcmFtZS4gSSBmZWVsIHRoZSBSYWRpb3RhcCBzdGFuZGFyZCBzaG91bGQgYWZmb3JkIHRoZSBk cml2ZXIgdGhlIG9wcG9ydHVuaXR5IHRvIGNvbnZleSB3aGF0IHdlbnQgd3Jvbmcgb24gdGhlIGFp ciwgZGVwZW5kaW5nIG9uIGhhcmR3YXJlIGNhcGFiaWxpdGllcyAoRGVsaW1pdGVyIENSQyBpcyBi YWQsIHdoYXQgdGhlIGJhZCBDUkMgdmFsdWUgaXRzZWxmIGlzLCBhbmQgYW55IHN1c3BlY3QgYnl0 ZXMgZm91bmQgYnkgaGFyZHdhcmUgd2hlcmUgdGhlIE1QRFUgc2hvdWxkIGhhdmUgYmVlbikuDQoN ClJlZ2FyZHMsDQpLcmlzaG5hDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Tue, 3 Jan 2012 17:25:40 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj4gRGlkIHlvdSBrZWVwIHRyYWNrIGFuZCB3YW50IHRvIHdyaXRlIHVwIGEgbmV3IHBy b3Bvc2FsPw0KDQpIZXJlIGlzIHRoZSBuZXcgcHJvcG9zYWwgYmFzZWQgb24gZWFybGllciBkaXNj dXNzaW9ucy4gVGhpcyBpcyBub3QgeWV0IGluIHN0YW5kYXJkIFJhZGlvdGFwIGZpZWxkIGRlZmlu aXRpb24gZm9ybWF0LiBUaGlzIGlzIGJlY2F1c2UgdGhlcmUgYXJlIHNvbWUgc3ViZmllbGRzIHdo aWNoIGhhdmUgbm90IGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSAob3IgaGF2ZSBiZWVuIHVwZGF0ZWQp LCBhbmQgdGhlIGdyb3VwIG1heSBoYXZlIGNvbW1lbnRzIG9uIHRoZXNlLiBDb21tZW50cyBvbiBw cmV2aW91c2x5IHNldHRsZWQgc3ViZmllbGRzIHRvbyBhcmUgd2VsY29tZS4NCg0KR3VpZGluZyBw cmluY2lwbGU6IFdlIGF0dGVtcHQgdG8gYXJyaXZlIGF0IGEgZmllbGQgZGVmaW5pdGlvbiB3aGlj aCBhbGxvd3MgZHJpdmVycy9oYXJkd2FyZSBjYXBhYmxlIG9mIHByb3ZpZGluZyBhZHZhbmNlZCBp bmZvcm1hdGlvbiB0byBkbyBzbywgaW4gdGhlIGludGVyZXN0IG9mIGJlaW5nIGFibGUgdG8gcmVj b25zdHJ1Y3Qgd2hhdGV2ZXIgaGFwcGVuZWQgb24gdGhlIGFpciBhcyBwcmVjaXNlbHkgYXMgcG9z c2libGUuIFRoaXMgYWR2YW5jZWQgaW5mb3JtYXRpb24gY292ZXJzIGJvdGggc3VjY2VzcyBhbmQg ZmFpbHVyZSBjb25kaXRpb25zLiBUaGlzIGNvdWxkIGFpZCBpbiBlbmhhbmNlZCBhbmFseXNpcy4g RHJpdmVyL2hhcmR3YXJlIGNvbWJpbmF0aW9ucyB3aXRoIGxlc3NlciBjYXBhYmlsaXR5IG1heSBz a2lwIHNvbWUgb2YgdGhlIHN1Yi1maWVsZHMgLSBXaXJlc2hhcmsgd2lsbCB3b3JrIHdpdGggd2hh dGV2ZXIgaXMgYXZhaWxhYmxlIGFuZCBwcm92aWRlIGNvcnJlc3BvbmRpbmdseSByZWR1Y2VkIGlu Zm9ybWF0aW9uLiANCg0KMSkgKE5ldykgRHJpdmVyIGdlbmVyYXRlZCBBLU1QRFUgcmVmZXJlbmNl IG51bWJlciAodTE2KS4gQWxsIHN1YmZyYW1lcyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgQS1NUERV IHdpbGwgaGF2ZSB0aGUgc2FtZSByZWZlcmVuY2UgbnVtYmVyIChidXQgc2VlIHJvbGxvdmVyIGNv bmRpdGlvbiBkaXNjdXNzZWQgc2hvcnRseSkuIFRoaXMgcmVmZXJlbmNlIG51bWJlciBhbGxvd3Mg dGhlIGRyaXZlciB0byByZWxpYWJseSBjb252ZXkgdG8gc25pZmZlciBhcHBsaWNhdGlvbiB3aGlj aCBzdWJmcmFtZXMgaXQgZm91bmQgdW5kZXIgdGhlIHNhbWUgQS1NUERVLCBpbmRlcGVuZGVudCBv ZiBkcml2ZXIgZGF0YSBwYXRoIGNoYXJhY3RlcmlzdGljcywgemVybyBNUERVIGxlbmd0aCBzdWJm cmFtZXMsIG1peCBvZiB0cmFmZmljIG9uIHRoZSBhaXIsIGFuZCB2YXJpb3VzIGVycm9yIGNvbmRp dGlvbnMuIFRoZSByZWZlcmVuY2UgbnVtYmVyIGlzIGNvbW1vbiBhY3Jvc3MgYWxsIHRyYWZmaWMg YW5kIG5vdCBtYWludGFpbmVkIHNlcGFyYXRlbHkgZm9yIHNlcGFyYXRlIERBLVNBIHBhaXJzIG9y IGFueSBzdWNoIHR1cGxlcy4NClJvbGxvdmVyIGlzIGVhc2lseSBoYW5kbGVkIGJ5IHNuaWZmZXIg YXBwbGljYXRpb24gdXNpbmcgdGltZXN0YW1wIGxvY2FsaXR5LiBTdWJmcmFtZXMgd2l0aCB0aGUg c2FtZSByZWZlcmVuY2UgbnVtYmVyIHdoaWNoIGRvbid0IGFjdHVhbGx5IGJlbG9uZyB0byB0aGUg c2FtZSBBLU1QRFUgKG93aW5nIHRvIHJvbGxvdmVyKSB3aWxsIGhhdmUgdGltZXN0YW1wcyBzZXZl cmFsIHNlY29uZHMgYXBhcnQuDQoyKSAoTmV3KSBBIGJpdCB0byBpbmRpY2F0ZSBpZiB0aGUgZHJp dmVyIGlzIGNhcGFibGUgb2YgcmV0dXJuaW5nIGluZm9ybWF0aW9uIGFib3V0IGluZGl2aWR1YWwg emVybyBNUERVIGxlbmd0aCBzdWJmcmFtZXMuDQozKSAoTmV3KSBBIGJpdCB0byBpbmRpY2F0ZSBp ZiB0aGUgY3VycmVudCBzdWJmcmFtZSBpcyBhIHplcm8gTVBEVSBsZW5ndGggc3ViZnJhbWUuIFZh bGlkIGlmIGJpdCDigJgy4oCZIGFib3ZlIGlzIHNldC4NCjQpIChVcGRhdGVkKSBJbmRleCBmaWVs ZDogWmVyby1iYXNlZCBpbmRleCBvZiB0aGUgc3ViZnJhbWUsIHdpdGhpbiB0aGUgQS1NUERVICh1 MTYpLiBUaGlzIGlzIGFwcGxpY2FibGUgdG8gemVybyBNUERVIGxlbmd0aCBzdWJmcmFtZXMgYXMg d2VsbCwgaWYgYml0IOKAmDLigJkgYWJvdmUgaXMgc2V0Lg0KNSkgQSBiaXQgdG8gaW5kaWNhdGUg aWYg4oCYNuKAmSBiZWxvdyBpcyB2YWxpZC4NCjYpIEEgYml0IHRvIGluZGljYXRlIGlmIHRoaXMg aXMgdGhlIGxhc3Qgc3ViZnJhbWUgaW4gdGhlIEEtTVBEVS4gVGhpcyBkb2VzIG5vdCBhcHBseSB0 byB6ZXJvIE1QRFUgbGVuZ3RoIHN1YmZyYW1lcy4NCjcpIChVcGRhdGVkKSBBIGJpdCB0byBpbmRp Y2F0ZSBpZiB0aGUgRGVsaW1pdGVyIENSQyBpcyBpbiBlcnJvci4gVGhpcyBpcyBhcHBsaWNhYmxl IHRvIHplcm8gTVBEVSBsZW5ndGggc3ViZnJhbWVzIGFzIHdlbGwsIGlmIGJpdCDigJgy4oCZIGFi b3ZlIGlzIHNldC4gSWYgdGhlIGRyaXZlci9oYXJkd2FyZSBkb2VzbuKAmXQgcGFzcyB1cHdhcmRz IHN1YmZyYW1lcyBmb3Igd2hpY2ggRGVsaW1pdGVyIENSQyBpcyBpbiBlcnJvciwgdGhlbiB0aGlz IGJpdCBzaG91bGQgYmUgY2xlYXJlZCAoaS5lLiAwKSBhbGwgdGhlIHRpbWUgLSBvbmx5IHN1Y2Nl c3NmdWxseSBwYXJzZWQgc3ViZnJhbWVzIHdpbGwgYmUgcGFzc2VkIHRvIHRoZSBzbmlmZmVyIGFw cGxpY2F0aW9uIChub3RlIHRoYXQgaGVyZSwgc3VjY2Vzc2Z1bGx5IHBhcnNlZCBkb2VzIG5vdCBu ZWNlc3NhcmlseSBtZWFuIHRoYXQgdGhlIDgwMi4xMSBGQ1MgdG9vIHdpbGwgYmUgdmFsaWQg4oCT IHRoZSB0d28gYXJlIGRpZmZlcmVudCkuDQpXZSBkb27igJl0IHByb3ZpZGUgYSBtZWFucyB0byBp bmRpY2F0ZSBpZiB0aGlzIGJpdCBpcyDigJhpbnZhbGlk4oCZLiBJZiBhIGRyaXZlciBkb2VzbuKA mXQga25vdyB3aGV0aGVyIHdoYXQgaXQgaXMgcGFzc2luZyB1cHdhcmRzIGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBwYXJzZWQgb3Igbm90LCBJTUhPIHRoZXJlIGNvdWxkIGJlIHNlcmlvdXMgaW1wbGVt ZW50YXRpb24gbWlzdGFrZXMgYXQgc29tZSBsZXZlbC4NCjgpIEEgYml0IHRvIGluZGljYXRlIGlm IOKAmDnigJkgYmVsb3cgaXMgdmFsaWQuDQo5KSBEZWxpbWl0ZXIgQ1JDIHZhbHVlIGl0c2VsZiAo OCBiaXRzKS4gQXBwbGljYWJsZSBvbmx5IGlmIHRoZSBEZWxpbWl0ZXIgQ1JDIGlzIGluIGVycm9y LCBpLmUuIGJpdCA3IGlzIHNldC4NCg0KKFRvIGFjY29tbW9kYXRlIHRoZSBjYXNlIHdoZXJlIGEg ZHJpdmVyL2hhcmR3YXJlIGNvbWJpbmF0aW9uIG1heSBiZSBjYXBhYmxlIG9mIHByb3ZpZGluZyB0 b3RhbCB6ZXJvIE1QRFUgYmFzZWQgcGFkZGluZyBsZW5ndGggYmVmb3JlIGEgZ2l2ZW4gc3ViZnJh bWUsIGJ1dCBub3QgaW5mbyBvbiBpbmRpdmlkdWFsIHplcm8gTVBEVSBzdWJmcmFtZXMgdGhlbXNl bHZlcywgc2hvdWxkIHdlIGFkZCBvbmUgbW9yZSBmaWVsZCB3aGljaCBkaXJlY3RseSBnaXZlcyB0 aGUgdG90YWwgcGFkZGluZyBsZW5ndGg/IEJpdCAyIHdpbGwgYmUgemVybyBpbiB0aGlzIGNhc2Uu IERpc2N1c3Npb24gMSB1bmRlciAnIFdpcmVzaGFyayBJbXBsZW1lbnRhdGlvbiBTdWdnZXN0aW9u cycgd2lsbCBnZXQgbW9kaWZpZWQpLiANCg0KV2lyZXNoYXJrIEltcGxlbWVudGF0aW9uIFN1Z2dl c3Rpb25zOg0KDQoxKSBJZiBiaXQgMiBpcyBzZXQgYnkgZHJpdmVyOiBUb3RhbCB2YWx1ZSBvZiB6 ZXJvIE1QRFUgbGVuZ3RoIHBhZGRpbmcgYmVmb3JlIGEgZ2l2ZW4gbm9uLXplcm8gbGVuZ3RoIE1Q RFUgY29udGFpbmluZyBzdWJmcmFtZSBzaG91bGQgYmUgY2FsY3VsYXRlZCBieSBXaXJlc2hhcmsu IElmIHRoZSBEZWxpbWl0ZXIgQ1JDIGlzIGluIGVycm9yIGZvciBhbnkgb2YgdGhlIHplcm8tbGVu Z3RoIE1QRFUgc3ViZnJhbWVzIGludm9sdmVkLCB0aGVuIHRoZSBwYWRkaW5nIHZhbHVlIHNob3Vs ZCBiZSBzZXQgdG8gaW52YWxpZCAoUXVlc3Rpb246IENhbiB3ZSBzZXQgdGhpcyB0byBzb21ldGhp bmcgbGlrZSDigJhpbmRldGVybWluYXRl4oCZIHRvIGRpZmZlcmVudGlhdGUgaXQgZnJvbSB0aGUg Y2FzZSB3aGVyZSBiaXQgMiBpcyAwLCBkZXNjcmliZWQgYmVsb3c/KQ0KSWYgYml0IDIgaXMgMCwg dGhlbiBXaXJlc2hhcmsgc2hvdWxkIHNldCB0aGUgcGFkZGluZyB2YWx1ZSB0byBpbnZhbGlkLg0K DQoyKSBJZiBEZWxpbWl0ZXIgQ1JDIGlzIGluIGVycm9yLCB0aGVuIHRoZSBoYXJkd2FyZSBtYXkg b3IgbWF5IG5vdCByZXR1cm4gdGhlIHN1c3BlY3QgTVBEVSBieXRlcy4NCiAgICBhKSBJZiBoL3cg ZG9lcyBub3QgcmV0dXJuIE1QRFUgYnl0ZXMsIHRoZW4gV2lyZXNoYXJrIGNhbiBkaXNwbGF5IGp1 c3QgdGhlIFJhZGlvdGFwIGhlYWRlciB3aXRob3V0IHRoZSBNUERVIGNvbnRlbnRzDQogICAgYikg SWYgaC93IGRvZXMgcmV0dXJuIHRoZSBzdXNwZWN0IE1QRFUgYnl0ZXMsIFdpcmVzaGFyayBtYXkg Y2Fycnkgb3V0IG9uZSBvZiB0aGUgZm9sbG93aW5nIGJhc2VkIG9uIGNvbmZpZ3VyYXRpb24gc2V0 dGluZ3M6DQogICAgICAgIGkpIERpc3BsYXkgdGhlIHN1c3BlY3QgTVBEVSBhcyBhIGJ1bmNoIG9m IHVuLWRpc3NlY3RlZCBieXRlcy4NCiAgICAgICAgaWkpIEF0dGVtcHQgYSBoZXVyaXN0aWMgZGlz c2VjdGlvbiBvZiB0aGUgTVBEVSBieXRlcy4gQnV0IG5vdGUgdGhhdCB0aGlzIGNhbiBnbyBxdWl0 ZSB3cm9uZyBkdWUgdG8gdW5jZXJ0YWludHkgYWJvdXQgdmFsaWRpdHkgb2YgTVBEVSBib3VuZGFy aWVzLg0KIA0KMykgSWYgRGVsaW1pdGVyIENSQyBpcyBub3QgaW4gZXJyb3IsIHRoZSBkcml2ZXIg d2lsbCBub3QgY29weSB0aGUgQ1JDIHZhbHVlIGZyb20gaGFyZHdhcmUuIFdpcmVzaGFyayBzaG91 bGQgY2FsY3VsYXRlIHRoZSB2YWx1ZSBpdHNlbGYuDQoNCjQpIChPcHRpb25hbCkgVmFsdWUgb2Yg c3ViZnJhbWUgcGFkZGluZyBsZW5ndGggYWZ0ZXIgdGhlIE1QRFUgY291bGQgYmUgY2FsY3VsYXRl ZCBhbmQgZGlzcGxheWVkIGJ5IFdpcmVzaGFyay4gVGhvdWdoIHRoaXMgY2FuIGJlIGVhc2lseSBj YWxjdWxhdGVkIGZyb20gTVBEVSBsZW5ndGgsIGl0IGlzIGdvb2QgdG8gaGVscCB1c2VycyBlYXNp bHkgb2JzZXJ2ZSBhbmQgZmlsdGVyIG9uIHRoaXMgdmFsdWUgd2l0aG91dCBoYXZpbmcgdG8gcmVz b3J0IHRvIGFueSBwb3N0IHByb2Nlc3Npbmcgc2NyaXB0cy4gSWYgdGhlIHZhbHVlIGlzIHJlYWRp bHkgb2JzZXJ2YWJsZSwgaXQgbWlnaHQgaGVscCBmb3IgZXhhbXBsZSwgYSBtb2JpbGUgYXBwIGRl dmVsb3BlciB3aXRoIG9ubHkgY3Vyc29yeSBrbm93bGVkZ2Ugb2YgODAyLjExbiB0byBjaGFuY2Ug dXBvbiBhbmQgaW5xdWlyZSBpbnRvIHRoZSByZWFzb24gZm9yIHRoZSBwYWRkaW5nLiBGb3IgcmVh bC10aW1lIGFwcHMgb3BlcmF0aW5nIGluIG5vaXN5IFJGIGVudmlyb25tZW50cywgYWRqdXN0aW5n IHRoZSBwYXlsb2FkIGJ5dGVzIHRvIG1pbmltaXplIHN1YmZyYW1lIHBhZGRpbmcgbWF5IGZvcm0g b25lIG9mIG1hbnkgbGl0dGxlIG9wdGltaXphdGlvbnMgIHRvIGV4dHJhY3QgYmV0dGVyIHBlcmZv cm1hbmNlIChkZXBlbmRpbmcgb24gdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MpLg0KDQpSZWdhcmRz LA0KS3Jpc2huYQ0KDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Wed, 04 Jan 2012 11:42:16 +0100 Message-ID: <1325673736.3339.27.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398C1F289-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi Rao, > 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. Cool, thanks. > 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. I like this. Maybe we should extend it to u32 though? Space probably isn't at a premium, and VHT might make the timing deduction harder in the future? If I understand correctly, this would be generated by the driver anyway (and I see easily how I could generate it in our drivers) > 2) (New) A bit to indicate if the driver is capable of returning > information about individual zero MPDU length subframes. Is that required/useful? It doesn't seem like per-frame information, and global things are hard to deduct out of per-frame information? > 3) (New) A bit to indicate if the current subframe is a zero MPDU > length subframe. Valid if bit =E2=80=982=E2=80=99 above is set. This seems good, but the if the driver isn't capable this bit would always be 0 obviously, so I'm not sure I see the need for '2'. > 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 =E2=80=982=E2=80=99 above is set. I guess a u16 will be sufficient even for VHT, right? The note about 0-length subframes seems pointless since they otherwise don't exist? > 5) A bit to indicate if =E2=80=986=E2=80=99 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. Right, they can't be last. > 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 =E2=80=982=E2= =80=99 above > is set. If the driver/hardware doesn=E2=80=99t pass upwards subframes f= or > 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 =E2=80=93 the tw= o are > different). > We don=E2=80=99t provide a means to indicate if this bit is =E2=80=98in= valid=E2=80=99. If a > driver doesn=E2=80=99t 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 =E2=80=989=E2=80=99 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. Makes sense. > (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).=20 Not sure -- it could generate one (or more?) padding frame(s) in that case, no? > Wireshark Implementation Suggestions: >=20 > 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 > =E2=80=98indeterminate=E2=80=99 to differentiate it from the case where= bit 2 is 0, > described below?) "indeterminate" would be not adding the field to the parse tree at all > 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. > =20 > 3) If Delimiter CRC is not in error, the driver will not copy the CRC > value from hardware. Wireshark should calculate the value itself. Or simply not display it I guess. > 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). What would it calculate, based on the data provided? johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Sun, 8 Jan 2012 13:43:30 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com>,<1325673736.3339.27.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1325673736.3339.27.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi,=0A= =0A= >> 1) (New) Driver generated A-MPDU reference number (u16). All subframes = =0A= >> belonging to the same A-MPDU will have the same reference number (but = =0A= >> see rollover condition discussed shortly). This reference number =0A= >> allows the driver to reliably convey to sniffer application which =0A= >> subframes it found under the same A-MPDU, independent of driver data =0A= >> path characteristics, zero MPDU length subframes, mix of traffic on =0A= >> the air, and various error conditions. The reference number is common = =0A= >> across all traffic and not maintained separately for separate DA-SA =0A= >> pairs or any such tuples.=0A= >> Rollover is easily handled by sniffer application using timestamp =0A= >> locality. Subframes with the same reference number which don't =0A= >> actually belong to the same A-MPDU (owing to rollover) will have =0A= >> timestamps several seconds apart.=0A= >I like this. Maybe we should extend it to u32 though? Space probably isn't= at a premium,=0A= >and VHT might make the timing deduction harder in the future?=0A= =0A= If space isn=92t at a premium, I agree we should make it u32. There might b= e some embedded system sniffers where this space still matters, since it is= multiplied by # of packets =96 but see discussion a paragraph later.=0A= =0A= Timing deduction can still be made with u16 in a VHT scenario. For the u16 = reference number to rollover in say 1 second, A-MPDUs would have to be rece= ived at an average rate of (1000000/65536)=3D15.25 microseconds. This avera= ge rate would have to be sustained over the period of the entire second. Ev= en with VHT, this may not happen in practical situations given Interframe S= pacing requirements (albeit reduced), contention, and intervening non-AMPDU= traffic. If for argument=92s sake we take a theoretical _sustained_ rate o= f one A-MPDU every 2 microseconds (which as per my current understanding, c= annot occur anyway), we still have a rollover spacing of >131 ms which is l= arge. It is much above the max time spacing between MPDUs in the same A-MPD= U for even 11n.=0A= =0A= But I now feel u32 will be preferable given that a) the VHT amendments are = still in draft b) there is always the possibility of other amendments in th= e future c) we would like a common simple criterion to be applied by the sn= iffer application which can work irrespective of current/future PHY paramet= ers and for all theoretical possibilities.=0A= =0A= >If I understand correctly, this would be generated by the driver =0A= =0A= That is correct. =0A= =0A= >> 2) (New) A bit to indicate if the driver is capable of returning =0A= >> information about individual zero MPDU length subframes.=0A= >Is that required/useful? It doesn't seem like per-frame information, and= =0A= >global things are hard to deduct out of per-frame information?=0A= =0A= The thought process behind adding that is as follows:=0A= a) If none of the subframes returned by the driver are marked as 0-subframe= s, the sniffer app has two ways of interpreting this, leading to confusion:= =0A= i) No 0-subframe padding was actually used over the air (valid since tM= MSS as defined in the standard can be zero).=0A= ii) Padding may or may not have been used over the air, but the driver = is not capable of indicating this, so it is unknown.=0A= Providing the same output to the end user for i) and ii) could be misleadin= g.=0A= To allow the sniffer app to come to the right conclusion, we need a way of = helping it reliably differentiate between i) and ii)=0A= =0A= b) Sniffer capture files can be filtered and saved into smaller files. The = differentiating information discussed in a) should survive this. =0A= =0A= c) Conversely, sniffer capture files can be combined (e.g., for multi-chann= el roaming performance analysis). Different sniffer drivers/hardware could = have been used for each channel. The differentiating information discussed = in a) should not get mixed up in such situations.=0A= =0A= d) The files, whether original or abridged, can be sent to other users not = having access to the original setup used for the capture.=0A= =0A= An explicit indication of the driver=92s capability to return info on 0-sub= frames was proposed as a means to solve problem a). Including it in every= frame was suggested as a means to solve b-d.=0A= =0A= But there may be better solutions. Requesting comments/alternatives from th= e group.=0A= =0A= Note:=0A= Some additional wireshark suggestions will be required (subject to comments= from the group regarding the above):=0A= - Bit 2 should be processed by wireshark for every single frame.=0A= - Due to c), =91Driver generated A-MPDU reference number=92 should be cons= idered separate for every channel.=0A= If the end user combines two different sniffer captures taken on the same c= hannel having overlapping absolute times, IMHO that is an end-user mistake.= =0A= =0A= >> 3) (New) A bit to indicate if the current subframe is a zero MPDU =0A= >> length subframe. Valid if bit =912=92 above is set.=0A= >This seems good, but the if the driver isn't capable this bit would=0A= >always be 0 obviously, so I'm not sure I see the need for '2'.=0A= =0A= See explanation above regarding why bit =912=92 might be required.=0A= Besides, if we retain bit 2, the sniffer app can first examine it, and if i= t is zero, it can skip two things at once:=0A= - examination of bit 3 here and=0A= - any additional 0-subframe related code while processing the Index field b= elow (depending on sniffer app design).=0A= =0A= >> 4) (Updated) Index field: Zero-based index of the subframe, within the = =0A= >> A-MPDU (u16). This is applicable to zero MPDU length subframes as =0A= >> well, if bit =912=92 above is set.=0A= >I guess a u16 will be sufficient even for VHT, right?=0A= =0A= Yes (there was one piece of information I couldn=92t manage to find in the = draft I have when verifying this, but it should be ok).=0A= =0A= For reasons similar to a) and b) under the discussion for =911) Driver gene= rated A-MPDU reference number=92, I propose making this a u32.=0A= =0A= >The note about 0-length subframes seems pointless since they otherwise don= 't exist?=0A= =0A= See discussions for bits 2 and 3 above.=0A= =0A= >> (To accommodate the case where a driver/hardware combination may be =0A= >> capable of providing total zero MPDU based padding length before a =0A= >> given subframe, but not info on individual zero MPDU subframes =0A= >> themselves, should we add one more field which directly gives the =0A= >> total padding length? Bit 2 will be zero in this case. Discussion 1 =0A= >> under ' Wireshark Implementation Suggestions' will get modified).=0A= >Not sure -- it could generate one (or more?) padding frame(s) in that case= , no?=0A= =0A= I agree. That will promote uniformity. It might increase the work for the d= river writer, depending on design, but that should be ok.=0A= =0A= >> Wireshark Implementation Suggestions:=0A= >> =0A= >> 1) If bit 2 is set by driver: Total value of zero MPDU length padding = =0A= >> before a given non-zero length MPDU containing subframe should be =0A= >> calculated by Wireshark. If the Delimiter CRC is in error for any of =0A= >> the zero-length MPDU subframes involved, then the padding value should = =0A= >> be set to invalid (Question: Can we set this to something like =0A= >> =91indeterminate=92 to differentiate it from the case where bit 2 is 0, = =0A= >> described below?)=0A= >"indeterminate" would be not adding the field to the parse tree at all=0A= =0A= Am not sure I understood this fully. If the field is not added to the parse= tree, and one tries to work with the value of this field using a filter ex= pression, or if one uses tshark to try and extract the value of the field, = what would be the outcome?=0A= (Sorry, I should be digging this from the Wireshark documentation or source= s. But I am a bit short on time, so thought of asking).=0A= =0A= >> 3) If Delimiter CRC is not in error, the driver will not copy the CRC = =0A= >> value from hardware. Wireshark should calculate the value itself.=0A= >Or simply not display it I guess.=0A= =0A= For the sake of uniformity, I think it would be good to display it.=0A= Besides, it would be beneficial for users trying to learn how things work o= n the air, from observation. =0A= May be we can keep it Optional like =914=92 below, for starters. It is ind= ependent of the Radiotap field definition anyway.=0A= =0A= >> 4) (Optional) Value of subframe padding length after the MPDU could be = =0A= >> calculated and displayed by Wireshark. Though this can be easily =0A= >> calculated from MPDU length, it is good to help users easily observe =0A= >> and filter on this value without having to resort to any post =0A= >> processing scripts. If the value is readily observable, it might help = =0A= >> for example, a mobile app developer with only cursory knowledge of =0A= >> 802.11n to chance upon and inquire into the reason for the padding.=0A= >> For real-time apps operating in noisy RF environments, adjusting the =0A= >> payload bytes to minimize subframe padding may form one of many little = =0A= >> optimizations to extract better performance (depending on traffic =0A= >> characteristics).=0A= >What would it calculate, based on the data provided?=0A= =0A= I didn=92t get which app you are referring to =96 Wireshark or the real-ti= me app?=0A= I was suggesting in my example that the developer of the real-time app woul= d gain knowledge about the padding behavior when experimenting with Wiresha= rk 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 wo= uld be, and then adjusts the # of app payload bytes (fed into the socket) t= o minimize the subframe-end padding wastage. This would be one among a seri= es of little optimizations (and it wouldn=92t work all the time).=0A= This is just an illustration.=0A= Again, it is independent of the Radiotap field definition.=0A= =0A= Regds,=0A= Krishna=0A= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Mon, 09 Jan 2012 11:16:06 +0100 Message-ID: <1326104166.3451.21.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398C20149-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi, > If space isn=E2=80=99t at a premium, I agree we should make it u32. The= re > might be some embedded system sniffers where this space still matters, > since it is multiplied by # of packets =E2=80=93 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. > >> 2) (New) A bit to indicate if the driver is capable of returning=20 > >> information about individual zero MPDU length subframes. > >Is that required/useful? It doesn't seem like per-frame information, > and > >global things are hard to deduct out of per-frame information? >=20 > The thought process behind adding that is as follows: [...] > An explicit indication of the driver=E2=80=99s capability to return inf= o on > 0-subframes was proposed as a means to solve problem a). Including > it in every frame was suggested as a means to solve b-d. Good points. > But there may be better solutions. Requesting comments/alternatives > from the group. I can't think of anything, and it's just a bit in there anyway. > Note: > Some additional wireshark suggestions will be required (subject to > comments from the group regarding the above): > - Bit 2 should be processed by wireshark for every single frame. > - Due to c), =E2=80=98Driver generated A-MPDU reference number=E2=80=99= should be > considered separate for every channel. > If the end user combines two different sniffer captures taken on the > same channel having overlapping absolute times, IMHO that is an > end-user mistake. That's an interesting point regarding channels -- I think that should be a note in the radiotap spec of the field (for implementation purposes) > >> 3) (New) A bit to indicate if the current subframe is a zero MPDU=20 > >> length subframe. Valid if bit =E2=80=982=E2=80=99 above is set. > >This seems good, but the if the driver isn't capable this bit would > >always be 0 obviously, so I'm not sure I see the need for '2'. >=20 > See explanation above regarding why bit =E2=80=982=E2=80=99 might be r= equired. > Besides, if we retain bit 2, the sniffer app can first examine it, and > if it is zero, it can skip two things at once: > - examination of bit 3 here and > - any additional 0-subframe related code while processing the Index > field below (depending on sniffer app design). Ok. > >> 4) (Updated) Index field: Zero-based index of the subframe, within > the=20 > >> A-MPDU (u16). This is applicable to zero MPDU length subframes as=20 > >> well, if bit =E2=80=982=E2=80=99 above is set. > >I guess a u16 will be sufficient even for VHT, right? >=20 > Yes (there was one piece of information I couldn=E2=80=99t manage to fi= nd in > the draft I have when verifying this, but it should be ok). >=20 > For reasons similar to a) and b) under the discussion for =E2=80=981) D= river > generated A-MPDU reference number=E2=80=99, I propose making this a u3= 2. Sounds good to me. > >> Wireshark Implementation Suggestions: > >>=20 > >> 1) If bit 2 is set by driver: Total value of zero MPDU length > padding=20 > >> before a given non-zero length MPDU containing subframe should be=20 > >> calculated by Wireshark. If the Delimiter CRC is in error for any > of=20 > >> the zero-length MPDU subframes involved, then the padding value > should=20 > >> be set to invalid (Question: Can we set this to something like=20 > >> =E2=80=98indeterminate=E2=80=99 to differentiate it from the case wh= ere bit 2 is > 0,=20 > >> described below?) > >"indeterminate" would be not adding the field to the parse tree at > all >=20 > Am not sure I understood this fully. If the field is not added to the > parse tree, and one tries to work with the value of this field using a > filter expression, or if one uses tshark to try and extract the value > of the field, what would be the outcome? > (Sorry, I should be digging this from the Wireshark documentation or > sources. But I am a bit short on time, so thought of asking). You can't work with the field then. It has no value, and any comparison will return false. This is why you can do things like just "radiotap.field" in a filter -- that checks that it exists. > >> 4) (Optional) Value of subframe padding length after the MPDU could > be=20 > >> calculated and displayed by Wireshark. Though this can be easily=20 > >> calculated from MPDU length, it is good to help users easily > observe=20 > >> and filter on this value without having to resort to any post=20 > >> processing scripts. If the value is readily observable, it might > help=20 > >> for example, a mobile app developer with only cursory knowledge of=20 > >> 802.11n to chance upon and inquire into the reason for the padding. > >> For real-time apps operating in noisy RF environments, adjusting > the=20 > >> payload bytes to minimize subframe padding may form one of many > little=20 > >> optimizations to extract better performance (depending on traffic=20 > >> characteristics). > >What would it calculate, based on the data provided? >=20 > I didn=E2=80=99t get which app you are referring to =E2=80=93 Wireshar= k or the > real-time app? Sorry, not sure -- either one? Any application that displays things? > 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=E2=80=99t 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? A-MPDU radiotap field ----------------------- bit index: TBD alignment: 4 bytes (u32) * ampdu reference number (u32) * 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? johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Sun, 15 Jan 2012 19:14:30 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com>,<1326104166.3451.21.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1326104166.3451.21.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi,=0A= =0A= >> If space isn=92t at a premium, I agree we should make it u32. There=0A= >> might be some embedded system sniffers where this space still matters,= =0A= >> since it is multiplied by # of packets =96 but see discussion a=0A= >> paragraph later.=0A= >Hm, not sure -- yes, it is multiplied, but it's still dwarfed by the=0A= >size of the packets -- this won't help much if your system is disk space= =0A= >constrained -- in that case you'll need to get the data out of it as=0A= >soon as possible anyway.=0A= I agree. In any case, we need the extra bytes for 'future-proofing'.=0A= =0A= >> I didn=92t get which app you are referring to =96 Wireshark or the=0A= >> real-time app?=0A= >Sorry, not sure -- either one? Any application that displays things?=0A= You summarized correctly below about the calculations in the illustration I= presented. =0A= =0A= >> I was suggesting in my example that the developer of the real-time app= =0A= >> would gain knowledge about the padding behavior when experimenting=0A= >> with Wireshark during a study phase. She could then develop the real=0A= >> time app such that it checks the TCP/IP and 802.11 settings to=0A= >> estimate what the MPDU size would be, and then adjusts the # of app=0A= >> payload bytes (fed into the socket) to minimize the subframe-end=0A= >> padding wastage. This would be one among a series of little=0A= >> optimizations (and it wouldn=92t work all the time).=0A= >> This is just an illustration.=0A= >> Again, it is independent of the Radiotap field definition.=0A= >Right. I had misunderstood you -- you wanted wireshark to display the=0A= >padding saying it could easily be calculated, and I thought you were=0A= >referring to a calculation wireshark would make, while you were in fact=0A= >referring to a calculation the user of wireshark would make. Sorry :)=0A= =0A= >So let me briefly recap what we talked about, is that accurate?=0A= Thanks for summarizing the field definitions. =0A= =0A= > A-MPDU radiotap field=0A= >-----------------------=0A= >bit index: TBD=0A= >alignment: 4 bytes (u32)=0A= >=0A= > * ampdu reference number (u32)=0A= We need to add a note about the reference number being different for every = channel.=0A= =0A= > * ampdu subframe index (u32) [*1]=0A= > * flags (u8?)=0A= > - 0x01: driver reports 0-length subframes=0A= > - 0x02: is 0-length subframe (valid if 0x01 set)=0A= > - 0x04: last subframe known=0A= > (should be set for all subframes if driver knows)=0A= > - 0x08: is last subframe in ampdu (valid if 0x04 set)=0A= > (clear for all but last subframe)=0A= > - 0x10: delimiter CRC error=0A= > - 0x20: delimiter CRC value known=0A= > * delimiter CRC value (u8) (valid if flag 0x20 set)=0A= >=0A= >=0A= >[*1] you said subframe index would be valid if driver reports 0-length=0A= >subframes -- why not a separate bit to indicate this is valid?=0A= 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 sub= frame is zero or non-zero MPDU length). The index value itself is zero-base= d (i.e., it starts from 0 and increments onwards).=0A= =0A= a) If 0x01 is set, then the index for the current subframe takes into accou= nt previous zero MPDU length subframes (because these previous zero subfram= es have been reported individually and the index incremented for each of th= em).=0A= b) If 0x01 is clear, then the index for the current subframe does not accou= nt for previous zero MPDU length subframes that might have been transmitted= over the air.=0A= =0A= Thus if two different drivers are observing the same traffic:=0A= 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 bef= ore that subframe). =0A= =0A= If 0x01 is set, then the sniffer app can calculate zero padding by processi= ng index information and MPDU length field values across subframes.=0A= =0A= Everything else looks good.=0A= =0A= Regds,=0A= Krishna.=0A= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Mon, 16 Jan 2012 14:46:39 +0100 Message-ID: <1326721599.3510.18.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> ,<1326104166.3451.21.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398C36652-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi, > > 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. Right, sorry, missed that. > > * 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. Ok, I misunderstood this then. > 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. Ok, but I think that then we still need to resolve a small ambiguity here. Imagine this: [mpdu][pad][pad][mpdu][pad][mpdu] a) 0 1 2 3 4 5 b) 0 1 2 Right? But now imagine a device misses a frame due to decode problem or so ... then which one would you want: 1) subframe index skips that one 2) subframe index just increases Say [mpdu][pad][pad][----][pad][mpdu] 1) 0 1 2 (3) 4 5 2) 0 1 2 3 4 but then the driver would have to guess at the padding? Not sure. In any case, we need to nail this down, because in the case 2) the driver can number the subframes (but it's less useful), and in the case 1) the device has to provide it (and not all do -- so we need a separate valid bit). In the case 1), even the application (wireshark) could provide the subframe index? johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Mon, 20 Feb 2012 12:03:29 +0100 Message-ID: <1329735809.3458.14.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> ,<1326104166.3451.21.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> <1326721599.3510.18.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C3D354@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398C3D354-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi, Sorry for the delay in reviewing this. > >But now imagine a device misses a frame due to decode problem or so ... > >then which one would you want: > >1) subframe index skips that one > >2) subframe index just increases > > > >Say > > [mpdu][pad][pad][----][pad][mpdu] > >1) 0 1 2 (3) 4 5 > >2) 0 1 2 3 4 > > > >but then the driver would have to guess at the padding? Not sure. In any case, we need to nail > >this down, because in the case 2) the driver can number the subframes (but it's less useful), > >and in the case 1) the device has to provide it (and not all do -- so we need a separate valid bit). > >In the case 1), even the application (wireshark) could provide the subframe index? > > Good you brought this up. > > I had basically case 2) in mind. Even the device itself may not always > be able to provide the index for subframes totally skipped due to > decode problems. Yes, good point. > It may sometimes be able to pass to the driver subframes with bad > delimiter CRC and these would get indexed by the driver (with flag > 0x10 set). So the principle is that only whatever subframes the device > can pass to the driver, good or bad, get indexed. > > But I now feel the application itself can provide the subframe > indexing (as in case 2). It can use the subframe reference number and > timestamp for this. The burden on the driver would be decreased, and > we also save space in the Radiotap header by removing this field. Makes sense to me. I guess that means we just remove the ampdu subframe index from the proposal, so we have this? A-MPDU radiotap field ----------------------- bit index: TBD alignment: 4 bytes (u32) * ampdu reference number (u32) * flags (u16) - 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) * u8 (reserved) (I added the reserved field and changed the flags to u16, it seems relatively likely that other fields will need u32 alignment so it seems reasonable to reserve a byte here, maybe for VHT extensions?) johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: RE: Regarding A-MPDU status field Date: Thu, 23 Feb 2012 16:48:57 +0100 Message-ID: <1330012137.3448.16.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> ,<1326104166.3451.21.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> <1326721599.3510.18.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C3D354@nasanexd02b.na.qualcomm.com> <1329735809.3458.14.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C55E21@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398C55E21-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Hi all, I've updated the wiki page for this, please see there: http://radiotap.org/suggested-fields/A-MPDU%20status Is everybody happy with the format etc.? Then we can start working on some patches. johannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Mon, 23 Jan 2012 16:16:14 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C3D354@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> ,<1326104166.3451.21.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> <1326721599.3510.18.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1326721599.3510.18.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj4+IEl0IHdvdWxkIHByb3ZpZGUgdGhlIHBvc2l0aW9uIG9mIHRoZSBjdXJyZW50IHN1 YmZyYW1lLCBpbiB3aXRoaW4gdGhlIA0KPj4gQS1NUERVIChpcnJlc3BlY3RpdmUgb2Ygd2hldGhl ciB0aGUgc3ViZnJhbWUgaXMgemVybyBvciBub24temVybyBNUERVIA0KPj4gbGVuZ3RoKS4gVGhl IGluZGV4IHZhbHVlIGl0c2VsZiBpcyB6ZXJvLWJhc2VkIChpLmUuLCBpdCBzdGFydHMgZnJvbSAw IA0KPj4gYW5kIGluY3JlbWVudHMgb253YXJkcykuDQo+PiANCj4+IGEpIElmIDB4MDEgaXMgc2V0 LCB0aGVuIHRoZSBpbmRleCBmb3IgdGhlIGN1cnJlbnQgc3ViZnJhbWUgdGFrZXMgaW50byANCj4+ IGFjY291bnQgcHJldmlvdXMgemVybyBNUERVIGxlbmd0aCBzdWJmcmFtZXMgKGJlY2F1c2UgdGhl c2UgcHJldmlvdXMgDQo+PiB6ZXJvIHN1YmZyYW1lcyBoYXZlIGJlZW4gcmVwb3J0ZWQgaW5kaXZp ZHVhbGx5IGFuZCB0aGUgaW5kZXggDQo+PiBpbmNyZW1lbnRlZCBmb3IgZWFjaCBvZiB0aGVtKS4N Cj4+IGIpIElmIDB4MDEgaXMgY2xlYXIsIHRoZW4gdGhlIGluZGV4IGZvciB0aGUgY3VycmVudCBz dWJmcmFtZSBkb2VzIG5vdCANCj4+IGFjY291bnQgZm9yIHByZXZpb3VzIHplcm8gTVBEVSBsZW5n dGggc3ViZnJhbWVzIHRoYXQgbWlnaHQgaGF2ZSBiZWVuIA0KPj4gdHJhbnNtaXR0ZWQgb3ZlciB0 aGUgYWlyLg0KPj4gDQo+PiBUaHVzIGlmIHR3byBkaWZmZXJlbnQgZHJpdmVycyBhcmUgb2JzZXJ2 aW5nIHRoZSBzYW1lIHRyYWZmaWM6DQo+PiBUaGUgZHJpdmVyIHRoYXQgc2V0cyAweDAxIHdpbGwg cmVwb3J0IGEgbGFyZ2VyIGluZGV4IHZhbHVlIGZvciBhIGdpdmVuIA0KPj4gbm9uLXplcm8gc3Vi ZnJhbWUsIHRoYW4gdGhlIGRyaXZlciB0aGF0IGNsZWFycyAweDAxIChpZiB6ZXJvIHBhZGRpbmcg DQo+PiBvY2N1cnMgYmVmb3JlIHRoYXQgc3ViZnJhbWUpLg0KPj4gDQo+PiBJZiAweDAxIGlzIHNl dCwgdGhlbiB0aGUgc25pZmZlciBhcHAgY2FuIGNhbGN1bGF0ZSB6ZXJvIHBhZGRpbmcgYnkgDQo+ PiBwcm9jZXNzaW5nIGluZGV4IGluZm9ybWF0aW9uIGFuZCBNUERVIGxlbmd0aCBmaWVsZCB2YWx1 ZXMgYWNyb3NzIA0KPj4gc3ViZnJhbWVzLg0KPk9rLCBidXQgSSB0aGluayB0aGF0IHRoZW4gd2Ug c3RpbGwgbmVlZCB0byByZXNvbHZlIGEgc21hbGwgYW1iaWd1aXR5IGhlcmUuIEltYWdpbmUgdGhp czoNCj4NCj4gICBbbXBkdV1bcGFkXVtwYWRdW21wZHVdW3BhZF1bbXBkdV0NCj5hKSAwICAgICAx ICAgIDIgICAgMyAgICAgNCAgICA1DQo+YikgMCAgICAgICAgICAgICAgIDEgICAgICAgICAgMg0K Pg0KPlJpZ2h0Pw0KQ29ycmVjdC4NCg0KPg0KPkJ1dCBub3cgaW1hZ2luZSBhIGRldmljZSBtaXNz ZXMgYSBmcmFtZSBkdWUgdG8gZGVjb2RlIHByb2JsZW0gb3Igc28gLi4uDQo+dGhlbiB3aGljaCBv bmUgd291bGQgeW91IHdhbnQ6DQo+MSkgc3ViZnJhbWUgaW5kZXggc2tpcHMgdGhhdCBvbmUNCj4y KSBzdWJmcmFtZSBpbmRleCBqdXN0IGluY3JlYXNlcw0KPg0KPlNheQ0KPiAgIFttcGR1XVtwYWRd W3BhZF1bLS0tLV1bcGFkXVttcGR1XQ0KPjEpIDAgICAgIDEgICAgMiAgICAoMykgICA0ICAgIDUN Cj4yKSAwICAgICAxICAgIDIgICAgICAgICAgMyAgICA0DQo+DQo+YnV0IHRoZW4gdGhlIGRyaXZl ciB3b3VsZCBoYXZlIHRvIGd1ZXNzIGF0IHRoZSBwYWRkaW5nPyBOb3Qgc3VyZS4gSW4gYW55IGNh c2UsIHdlIG5lZWQgdG8gbmFpbA0KPnRoaXMgZG93biwgYmVjYXVzZSBpbiB0aGUgY2FzZSAyKSB0 aGUgZHJpdmVyIGNhbiBudW1iZXIgdGhlIHN1YmZyYW1lcyAoYnV0IGl0J3MgbGVzcyB1c2VmdWwp LA0KPmFuZCBpbiB0aGUgY2FzZSAxKSB0aGUgZGV2aWNlIGhhcyB0byBwcm92aWRlIGl0IChhbmQg bm90IGFsbCBkbyAtLSBzbyB3ZSBuZWVkIGEgc2VwYXJhdGUgdmFsaWQgYml0KS4NCj5JbiB0aGUg Y2FzZSAxKSwgZXZlbiB0aGUgYXBwbGljYXRpb24gKHdpcmVzaGFyaykgY291bGQgcHJvdmlkZSB0 aGUgc3ViZnJhbWUgaW5kZXg/DQoNCkdvb2QgeW91IGJyb3VnaHQgdGhpcyB1cC4NCg0KSSBoYWQg YmFzaWNhbGx5IGNhc2UgMikgaW4gbWluZC4gRXZlbiB0aGUgZGV2aWNlIGl0c2VsZiBtYXkgbm90 IGFsd2F5cyBiZSBhYmxlIHRvIHByb3ZpZGUgdGhlIGluZGV4IGZvciBzdWJmcmFtZXMgdG90YWxs eSBza2lwcGVkIGR1ZSB0byBkZWNvZGUgcHJvYmxlbXMuIEl0IG1heSBzb21ldGltZXMgYmUgYWJs ZSB0byBwYXNzIHRvIHRoZSBkcml2ZXIgc3ViZnJhbWVzIHdpdGggYmFkIGRlbGltaXRlciBDUkMg YW5kIHRoZXNlIHdvdWxkIGdldCBpbmRleGVkIGJ5IHRoZSBkcml2ZXIgKHdpdGggZmxhZyAweDEw IHNldCkuIFNvIHRoZSBwcmluY2lwbGUgaXMgdGhhdCBvbmx5IHdoYXRldmVyIHN1YmZyYW1lcyB0 aGUgZGV2aWNlIGNhbiBwYXNzIHRvIHRoZSBkcml2ZXIsIGdvb2Qgb3IgYmFkLCBnZXQgaW5kZXhl ZC4NCg0KQnV0IEkgbm93IGZlZWwgdGhlIGFwcGxpY2F0aW9uIGl0c2VsZiBjYW4gcHJvdmlkZSB0 aGUgc3ViZnJhbWUgaW5kZXhpbmcgKGFzIGluIGNhc2UgMikuIEl0IGNhbiB1c2UgdGhlIHN1YmZy YW1lIHJlZmVyZW5jZSBudW1iZXIgYW5kIHRpbWVzdGFtcCBmb3IgdGhpcy4gVGhlIGJ1cmRlbiBv biB0aGUgZHJpdmVyIHdvdWxkIGJlIGRlY3JlYXNlZCwgYW5kIHdlIGFsc28gc2F2ZSBzcGFjZSBp biB0aGUgUmFkaW90YXAgaGVhZGVyIGJ5IHJlbW92aW5nIHRoaXMgZmllbGQuDQoNClJlZ2RzLA0K S3Jpc2huYQ0KDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rao, Krishna" Subject: RE: Regarding A-MPDU status field Date: Wed, 22 Feb 2012 01:14:19 +0000 Message-ID: <21E1C3B49A18BA428D58607D5EEA5398C55E21@nasanexd02b.na.qualcomm.com> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> <1320223343.3950.29.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BB67FA@nasanexd02b.na.qualcomm.com> ,<1320847366.3845.72.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BBBD18@nasanexd02b.na.qualcomm.com> ,<1321259214.4472.16.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398BC8C00@nasanexd02b.na.qualcomm.com> <1321867620.3999.7.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C1F289@nasanexd02b.na.qualcomm.com> ,<1325673736.3339.27.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C20149@nasanexd02b.na.qualcomm.com> ,<1326104166.3451.21.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C36652@nasanexd02b.na.qualcomm.com> <1326721599.3510.18.camel@jlt3.sipsolutions.net> <21E1C3B49A18BA428D58607D5EEA5398C3D354@nasanexd02b.na.qualcomm.com> <1329735809.3458.14.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1329735809.3458.14.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org> Content-Language: en-US Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: Johannes Berg Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org SGksDQoNCj5NYWtlcyBzZW5zZSB0byBtZS4gSSBndWVzcyB0aGF0IG1lYW5zIHdlIGp1c3QgcmVt b3ZlIHRoZSBhbXBkdSBzdWJmcmFtZSBpbmRleCBmcm9tIHRoZSBwcm9wb3NhbCwgc28gd2UgaGF2 ZSB0aGlzPw0KVGhlIGJlbG93IGxvb2tzIGdvb2QuIFlvdSBjYW4gYWxzbyBhZGQgYW4gaW1wbGVt ZW50YXRpb24gbm90ZSB0aGF0IHRoZSBzbmlmZmVyIGFwcGxpY2F0aW9uIHNob3VsZCBvcmRlciB0 aGUgc3ViZnJhbWVzIHVzaW5nIHRoZSBBLU1QRFUgcmVmZXJlbmNlIG51bWJlciBhbmQgdGltZXN0 YW1wLg0KDQo+IEEtTVBEVSByYWRpb3RhcCBmaWVsZA0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Yml0IGluZGV4OiBUQkQNCj5hbGlnbm1lbnQ6IDQgYnl0ZXMgKHUzMikNCg0KPiogYW1wZHUg cmVmZXJlbmNlIG51bWJlciAodTMyKQ0KSSBhc3N1bWUgeW91IHdpbGwgYmUgYWRkaW5nIHRoZSBu b3RlIGFib3V0IHRoZSByZWZlcmVuY2UgbnVtYmVyIGJlaW5nIGRpZmZlcmVudCBmb3IgZXZlcnkg Y2hhbm5lbC4uLg0KDQo+KiBmbGFncyAodTE2KQ0KPiAgLSAweDAxOiBkcml2ZXIgcmVwb3J0cyAw LWxlbmd0aCBzdWJmcmFtZXMNCj4gIC0gMHgwMjogaXMgMC1sZW5ndGggc3ViZnJhbWUgKHZhbGlk IGlmIDB4MDEgc2V0KQ0KPiAgLSAweDA0OiBsYXN0IHN1YmZyYW1lIGtub3duDQo+ICAgICAgICAg IChzaG91bGQgYmUgc2V0IGZvciBhbGwgc3ViZnJhbWVzIGlmIGRyaXZlciBrbm93cykNCj4gIC0g MHgwODogaXMgbGFzdCBzdWJmcmFtZSBpbiBhbXBkdSAodmFsaWQgaWYgMHgwNCBzZXQpDQo+ICAg ICAgICAgICAoY2xlYXIgZm9yIGFsbCBidXQgbGFzdCBzdWJmcmFtZSkNCj4gICAtIDB4MTA6IGRl bGltaXRlciBDUkMgZXJyb3INCj4gICAtIDB4MjA6IGRlbGltaXRlciBDUkMgdmFsdWUga25vd24N Cj4gKiBkZWxpbWl0ZXIgQ1JDIHZhbHVlICh1OCkgKHZhbGlkIGlmIGZsYWcgMHgyMCBzZXQpDQo+ ICogdTggKHJlc2VydmVkKQ0KDQo+KEkgYWRkZWQgdGhlIHJlc2VydmVkIGZpZWxkIGFuZCBjaGFu Z2VkIHRoZSBmbGFncyB0byB1MTYsIGl0IHNlZW1zIHJlbGF0aXZlbHkgbGlrZWx5IHRoYXQgb3Ro ZXIgZmllbGRzIHdpbGwgbmVlZCB1MzIgYWxpZ25tZW50IHNvIGl0IHNlZW1zIHJlYXNvbmFibGUg dG8gcmVzZXJ2ZSBhIGJ5dGUgaGVyZSwgbWF5YmUgZm9yIFZIVCBleHRlbnNpb25zPykNCk1ha2Vz IHNlbnNlLg0KDQpSZWdkcywNCktyaXNobmENCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: Regarding A-MPDU status field Date: Thu, 05 Jul 2012 11:49:11 +0200 Message-ID: <1341481751.4455.37.camel@jlt3.sipsolutions.net> References: <21E1C3B49A18BA428D58607D5EEA5398BB2E90@nasanexd02b.na.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21E1C3B49A18BA428D58607D5EEA5398BB2E90-RqevaKtL5OWBP98+muIrrKRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org> Sender: radiotap-owner-sUITvd46vNxg9hUCZPvPmw@public.gmane.org To: "Rao, Krishna" Cc: "radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org" List-Id: radiotap@radiotap.org Anyone have a wireshark patch for this (http://www.radiotap.org/suggested-fields/A-MPDU%20status) yet? I'm working on Linux kernel support right now. johannes