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.