On Jan 17, 2009, at 6:50 PM, Tal Rusak wrote:
I need to read several OmniPeek capture files. I read in the
archives
that it was not possible to display RSSI in dBm from these files in
previous versions.
There is currently no mechanism by which the code to read files from
later versions of AiroPeek, and from OmniPeek, can pass a "signal
level in dBm" value to the code that processes packets.
I am wondering if this is still the case, or if
some workaround has been developed.
There's no "workaround" for this other than "read it in a program
other than Wireshark". The mechanism by which radio information is
passed for most capture file types would have to be extended to allow
code that reads capture files to indicate that a "signal level in dBm"
value is present and to supply that value. The mechanism that's
currently being used doesn't have any way to indicate whether
particular values are present; it thus can't handle capture file
formats where *only* a signal level as a percentage, or *only* a
signal level in dBm, is supplied, and there *are* capture file formats
of that type.
Ideally, there would be a way in which all capture file readers can
supply radio information in a standard file-format-independent (and
radio-header-independent) format, and possibly also supply the raw
radio information (so that it can be written out exactly as it
appeared in the input file, if the output file format is the same as
the input file format, and so that there can be dissectors for it, if
we need to do reverse engineering or debug a driver's radiotap or AVS
or... header).
Nobody's designed or implemented that yet, however.
