Wireshark · Wireshark-dev: Re: [Wireshark-dev] Adding more information to 802.11 radio

[Guy Harris <guy@xxxxxxxxxxxx>]

On Mar 19, 2013, at 9:27 AM, atul kumar <bitsatul@xxxxxxxxx> 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.)