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.)
