Re: Adding more information to 802.11 radio

[Guy Harris <guy () alum mit edu>]

On Mar 19, 2013, at 9:27 AM, atul kumar <bitsatul () gmail com> wrote:

> I felt like taking your suggestions , regarding few of modification i intent to do in 802.11 radio information.
>
> Actually I want to added 802.11n params like ShorGi,LongGi,Aggregation[Ampdu/Amsdu] , along with already existing 
> DataRate,Channel,Rssi.
>
> So in short , I am trying to enhance or populate more of phyLayer information.
>
> Is it possible to add it ,

Yes, but we're not the ones who control that.  Wireshark reads what it's given; it does not, and will not, define its 
own file format or its own radio metadata format.  We want interoperability, not our own unique and proprietary file 
and metadata formats.

The most commonly used radio metadata format on UN*X systems (Linux, *BSD, and OS X) is radiotap.  The group 
responsible for radiotap is the radiotap.org group:

        http://www.radiotap.org

See the "defined-fields" page:

        http://www.radiotap.org/defined-fields

for stuff that radiotap *already* supports.  In particular, see:

        http://www.radiotap.org/defined-fields/MCS

which *already* has a guard interval flag that indicates whether there's a long or short GI, so there's nothing to add 
if you're going to be using radiotap headers.

See also

        http://www.radiotap.org/defined-fields/A-MPDU%20status

to see if that provides some of the aggregation information you want.

If there's additional information you want, check to see whether it's already been proposed:

        http://www.radiotap.org/suggested-fields

and:

        if it has, join the radiotap.org mailing list (instructions are on the http://www.radiotap.org/Radiotap page) 
and participate in the discussions about that proposal;

        if it hasn't, join that list and propose it (there appears to be a form on the 
http://www.radiotap.org/suggested-fields page for proposing new fields; I don't know how that works).

Note, by the way, that RSSI is *not* one of the defined fields.  Instead, there are fields that give antenna signal 
power either in dBm:

        http://www.radiotap.org/defined-fields/Antenna%20signal

or in dB from an arbitrary reference point:

        http://www.radiotap.org/defined-fields/dB%20antenna%20noise

There is a suggested RSSI field:

        http://www.radiotap.org/suggested-fields/RSSI

but it's only suggested because OpenBSD implements it, and, unfortunately, the OpenBSD people decided to pick a code 
("presence bit" value) for it that is the same as the code for an existing defined field, so it *really* shouldn't be 
used. If the antenna signal power (and antenna noise power) values aren't sufficient for your purposes, you should 
advocate the adoption of the RSSI field - with a different code value! - on the radiotap.org mailing list.

The other significant format, used on some UN*Xes (OS X, at least) and used (along with, I think, radiotap) by AirPcap, 
is the PPI format:

        http://www.cacetech.com/documents/PPI%20Header%20format%201.0.7.pdf

I don't know to what extent that's being extended.  It's less widely used than radiotap, so if you use it, there may be 
fewer tools that can handle it.  (Wireshark is not, and I, at least, have no interest in having it become, the one and 
only tool for all capture file processing.)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe