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] WLAN APC file and RSSI

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 23 Jan 2008 18:00:26 -0800

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.)