Date: Thu, 11 Mar 2010 19:40:43 +0100 From: Alexander Egorenkov <egorenar@googlemail.com> To: Rui Paulo <rpaulo@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: net80211 and PPI header Message-ID: <2d3b7e441003111040q53c3b8a7x77ac359beed121fc@mail.gmail.com> In-Reply-To: <89EB5317-6E66-4568-9FAC-68FD877BD7D0@freebsd.org> References: <2d3b7e441002100446k36493e24ldef6d4e335092b7f@mail.gmail.com> <4B73274E.1050902@freebsd.org> <2d3b7e441002101401x2f6f5f28i5ee3b63c18e6b1ed@mail.gmail.com> <4B80595F.2050406@errno.com> <C09F205D-14FE-47C2-A415-36624D0605D7@freebsd.org> <4B805E20.6030507@errno.com> <89EB5317-6E66-4568-9FAC-68FD877BD7D0@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
So how soon can we expect A-MPDU support in radiotap header ? On Sun, Feb 21, 2010 at 12:25 AM, Rui Paulo <rpaulo@freebsd.org> wrote: > On 20 Feb 2010, at 22:11, Sam Leffler wrote: > > > Rui Paulo wrote: > >> On 20 Feb 2010, at 21:51, Sam Leffler wrote: > >>> Alexander Egorenkov wrote: > >>>>> What exactly do you need? We should be able to extend radiotap. > >>>>> > >>>> 1. Not only one RSSI but for every antenna (also in dBm) > >>>> 2. HT greenfield/HT mixed indicator > >>>> 4. Number of spatial streams (STBC) > >>>> 3. A-MPDU support (MPDU density, A-MPDU reassembly) > >>>> The most important one is A-MPDU support, i think. > >>>> Wireshark supports PPI header and can handle A-MPDUs very nicely. > >>>> That's it for now :-) > >>> I discussed integrating PPI w/ radiotap back when I did the existing > 11n support but never got anywhere (>3 years ago?). The PPI stuff was done > under contract to Intel and the folks involved never contacted anyone about > doing it within radiotap instead. It looked entirely possible to leverage > the PPI decoder in wireshark to handle AMPDU reassembly from the radiotap > decoder but I never got to it. > >>> > >>> As to the other state Greenfield was nonexistent (and unclear if it'd > make it out of draft status) when I did stuff or I'd have reserved a bit for > it. The # of streams can be implied from the MCS unless I misunderstand. I > do want the per-antenna/chain state (rssi, nf, evm) but was looking for > things to stabilize before adding to radiotap--each device/driver exports > different data and I wanted something that was enough of a superset to > handle the most devices. Adopting PPI data structures would be reasonable. > >>> > >>> I would prefer to not emit PPI but instead augment radiotap. We've > standardized on radiotap for 802.11 and all the drivers now use it (or > should use it). I'll leave it to others to deal w/ the politics of the > radiotap noobs; the technical details of doing this are straightforward. > >> FWIW, I have very basic support of PPI headers on my 11n branch. > > > > What do you get from PPI that you care about that's missing in radiotap? > If it's just the ampdu reassembly I think we can do that within radiotap > w/o extra meta data. > > > > I haven't added the necessary driver support, so it was just a WIP. Like I > said I wasn't sure if it was better to extend radiotap or to implement PPI. > > > After working so long to get a single packet capture format in place I'm > loathe to add PPI. > > Yeah following the KISS principle would be great. All we have to do would > be to patch wireshark. > > -- > Rui Paulo > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2d3b7e441003111040q53c3b8a7x77ac359beed121fc>