Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] bug: -T fields -e wlan.signal_strength

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 09 Dec 2007 14:25:11 -0800
sfayssal@xxxxxxxxxxxxxxxxx wrote:

I am using the 0.99.6 on linux fc5, I am using -T fields -e
wlan.signal_strength, I tried almost all wlan.xxx,

Which ones did you try?  Did you try, for example, wlan.fc?

it is running fine but the
fields of wlan are not showing on the screen

Which fields, other than wlan.data_rate, wlan.channel, and wlan.signal_strength don't show?

although they are showing when I
use -T text,

How does the signal strength show?  Does it show as

	Signal Strength: N%

or

	Signal: N

or

	SSI Signal: N

or

	SSI Signal (dBm): N

or

	SSI Signal (dB): N

for some value of "N"?

If the only fields that don't display are wlan.data_rate, wlan.channel, and wlan.signal_strength, and with "-T text" the signal strength displays as anything other than

	Signal Strength: N%

then:

is it a bug, or the field name wlan.signal_strength ... is not
correct?

...the answer to the second question is "the field name wlan.signal_strength ... is not correct", and the answer to the first question is "well, if it's not a bug, it's at least a misfeature".

If you're trying to use this on traffic captured on Linux (or any other UN*X), the radio information, such as signal strength, is in a Prism, AVS, or radiotap header.

Currently, the Prism, AVS, and radiotap headers are not parsed by the 802.11 ("wlan") dissector, but by their own dissectors, which means that the fields such as wlan.signal_strength are not present - the fields are different.

For the Prism header, the signal strength is "prism.signal_data"; for the AVS header, it's "wlancap.ssi_signal"; and for the radiotap header, it's "radiotap.dbm_antsignal" or "radiotap.db_antsignal", depending on whether the driver reports it as dBm or dB.

What we should probably do is:

change the pseudo-header for 802.11 to be a combination of a radiotap-like header and some additional values (each one with a "is it present" flag) corresponding to radio values that are in some capture file or header formats but that don't have a radiotap value;

have the wiretap code for reading libpcap files generate that pseudo-header from the Prism, AVS, and radiotap headers, and have the code for writing them generate the appropriate file headers from that pseudo-header;

get rid of the Prism, AVS, and radiotap dissectors, and have the 802.11 dissector parse the pseudo-header.

That way, at least, if two capture file formats contain the same piece of radio information, they'll report it with the same wlan field. (There's still no guarantee that the signal strength will always be reported with the same field, as different cards and drivers report it differently, as far as I can tell.)