So how soon can we expect A-MPDU support in radiotap header ? On Sun, Feb 21, 2010 at 12:25 AM, Rui Paulo <rpa...@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 > > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
