Ethereal-dev: Re: [Ethereal-dev] [PATCH] Adding new columns for IEEE 802.11 use

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 5 Jul 2004 02:54:37 -0700
On Sat, Jul 03, 2004 at 11:57:14PM -0700, Jouni Malinen wrote:
> Couple of new columns values would be useful when using Ethereal as a
> wireless sniffer. The attached patch adds wireless meta data, TX rate
> and RSSI, as new optional column values.

Checked in...

...along with additional changes to attempt to make it equally useful
when using Ethereal on {FreeBSD 5.2 or later,NetBSD 2.0 beta or later}
or on Linuxes where the card supplies Prism headers rather than AVS
headers, and when reading captures from various Windows 802.11 analyzer
applications.

The data rate columns should be correct for all of those.

The RSSI might not.

The AVS header spec:

	http://www.shaftnet.org/~pizza/software/capturefrm.txt

says that the ssi_signal (signal strength) value can be missing, or a
"normalized RSSI" (a value in the range [0-1000]), or a dBm signal
strength value, or a "raw RSSI" value (I don't know how that should be
interpreted.  

The "ieee80211_radiotap.h" header from the current CVS NetBSD lists

	IEEE80211_RADIOTAP_DBM_ANTSIGNAL

which is "RF signal power at the antenna, decibel difference from one
milliwatt" and

	IEEE80211_RADIOTAP_DB_ANTSIGNAL

which is "RF signal power at the antenna, decibel difference from an
arbitrary, fixed reference".

The Prism header, at least according to "packet-prism.c", contains
"rssi", "sq", and "signal" values.  I assume "sq" is "signal quality";
is "rssi" is "received signal strength indication" or "raw signal
strength indication"?

> Are there any recommendations or instractions on how to select a format
> string for new columns?

No.

> Now, I just picked up two unique characters, but
> this is not very scalable when the number of possible column data
> increases.

Perhaps we shouldn't require single letters - there are some two-letter
and 3-letter format strings, although the parsing in
"get_column_format_from_str()" doesn't look up the strings in the
"slist[]" table, which it might have to do in order to make multi-letter
format strings work.  (I'm not sure what "for real" means in the comment
in "get_column_format_from_str()", but if it means the string can
contain other text, which would be put into the columns, that'd be a bit
more work, although that might be doable as well.)

BTW, now that more protocol-specific column types are being added,
perhaps we should have a way for protocol dissectors to register column
types by name and get COL_ values.