Avi Berkovich wrote:
Well, I went through the wiretap library code and saw that while it's
aware of the dBm tag (it has it's own "switch case"), it just doesn't
read it.
The problem is that, for 802.11 radio information other than in libpcap
files (where the radio information appears in the packet data as a
header preceding the 802.11 header), it's presented to the 802.11
dissector as a "pseudo-header".
That pseudo-header was originally introduced for the file format used by
AiroPeek before *Peek switched to the new file format (the old file
format is handled by wiretap/etherpeek.c, because the code to handle it
was first added to handle files from EtherPeek; the new file format is
handled by wiretap/airopeek9.c, because the code to handle it was first
added to handle files from a later version of AiroPeek (the URL
mentioned in airopeek9.c says 2.0.1)).
The older versions of AiroPeek had a fixed-length radio header, with a
1-byte data rate value in 500Kb/s units, a 1-byte channel value with a
channel number and a 1-byte signal level value as a percentage. Those
were the only values put into the pseudo-header; some other file formats
also use it.
The newer versions of EtherPeek, AiroPeek, and presumably OmniPeek, have
a variable-length TLV-based pseudo-header, with tags for both signal and
noise as a percentage and as a dBm value, as well as other tags
(including one mysterious one seen in an EtherPeek capture). The
current pseudo-header has no provision for most of those values, so most
of them are ignored.
There are a couple of ways to handle this:
1) have a new pseudo-header that can handle all the radio
pseudo-information found in capture files - including in the Prism, AVS,
and radiotap headers in libpcap - and funnel all radio information
through that.
2) have some mechanism for supplying the raw new-style *Peek TLV header
and have a dissector for it - and perhaps even use that for the
old-style *Peek header, CommView header, etc..
1) has the advantage that all the code that knows about particular forms
of radio information is in Wiretap, and no dissectors or taps need know
those details.
2) has the advantages that:
1) we could have an option in the 802.11 dissector to have it either
just display the extracted radio information (just the values) or
display a dissection of the raw header - the former is probably what
most users want (they don't care about the gory details of how a
radiotap, AVS, or Prism header encodes that information), and the latter
would be useful if you're debugging a driver generating a radiotap or
AVS header or are trying to reverse-engineer a radio header);
2) there's no loss of information from transforming the header to a
pseudo-header, so if you save packets from a capture the radio
information will be saved as is.
You *would* need multiple radio-information dissectors, but those could,
at least, build a pseudo-header to hand to taps, so the taps would be
independent of the capture file you're reading.
