Wireshark-users: Re: [Wireshark-users] radiotap RSSI v.s. IEEE802.11 RSSI
On Jun 26, 2009, at 7:42 AM, iodavide@xxxxxxxxx wrote:
I'm using Atheros device and I'm capturing data from monitor interface
using Radiotap
To better understand link quality I've selected two columns:
IEEE 802.11 RSSI
At least as I read IEEE 802.11-2007, RSSI is just some positive number
such that
1) it's between 0 and some maximum;
2) the greater the value, the more power is being received at the
antenna;
with no indication of what it means other than that.
What Wireshark displays in the "RSSI" column depends on the type of
capture; at least in the top-of-SVN-tree version:
for captures from AiroPeek, it's a percentage - RSSI/max_RSSI*100 (as
that's what AiroPeek saves to the file, at least as I read one of
WildPackets' documents);
for captures from CommView, it's a percentage - probably the same as
AiroPeek, but I didn't find anything obvious in their document to
indicate what it is;
for captures from Windows Sniffer, I *suspect* it's a percentage,
probably the same as AiroPeek;
for captures from Shomiti's wireless version of Surveyor (Finisar no
longer seem to offer it), I don't know what it is;
for pcap captures with Prism headers, it's whatever the heck the
particular driver puts there - a quick look at the drivers didn't
indicate that they put anything there;
for pcap captures with AVS headers, it's signal strength as either:
"Normalized RSSI" - integers in the range [0-1000] where higher
numbers indicate stronger signal, with no particular mapping to an
actual signal strength;
dBm - an actual received signal strength, in dBm;
a raw RSSI value, which is probably the raw IEEE RSSI value;
with the column indicating which it is;
for pcap captures with Radiotap headers, it's radiotap.dbm.antsignal,
shown as dBm.
and a custom colums radiotap.dbm.antsignal
I'm very surprise
to see different values for those columns
Given that the Radiotap code, at least in the top-of-tree version of
Wireshark just puts up the radiotap.dbm.antsignal value, I'd be
*extremely* susprised to see different values.
The 1.2.0 code should behave the same as the top-of-SVN-tree version;
what version of Wireshark are you using?
