On Jan 23, 2008, at 1:15 PM, Guy Harris wrote:
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.
...as was, in fact, noted in the comment in front of
airopeekv9_process_header():
* XXX - we should supply the additional radio information;
* the pseudo-header should probably be supplied in a fashion
* similar to the new BSD radio header, so that the 802.11
* dissector can determine which, if any, information items
* are present.
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.
...although Wiretap has to parse the new-style *Peek TLV header
*anyway*, as the packet length and slice length (captured length) are
part of that header.
It might be that going with a new-style pseudo-header is good enough -
yes, if we use that for libpcap, it would mean that you can't just use
Wireshark to debug your wireless adapter driver if it's generating a
mangled radiotap/AVS/Prism header, but I'm not sure whether that's
worth worrying about. There is some risk of loss of information if we
don't handle some particular attribute in a particular capture file
format, but it might be that the right way to fix that is to add said
support if we run into such a capture file.
(Another alternative is to supply both the raw radio information *and*
the parsed radio information as pseudo-headers, have different
WTAP_ENCAP types for different forms of raw radio information, and
supply both forms of radio information when writing a capture; that way
1) you'd still have the raw radio information for those users who
want to see it
and
2) at least when writing out packets in the format of the file from
which they're read, we can just pass the raw radio information
through, and not lose any information.)
