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

Wireshark-users: Re: [Wireshark-users] OmniPeek Capture File

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sat, 17 Jan 2009 19:11:08 -0800

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.