Wireshark-dev: Re: [Wireshark-dev] Writing a wtap module for CommView WLAN Analyzer and Decoder

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sun, 18 Apr 2021 21:29:42 -0700
On Apr 18, 2021, at 2:33 PM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:

> I am thinking of writing a wtap module to read ComView WLAN Analyzer
> and Decoder NCFS format files.
> 
> They are a little like PCAP files with a radiotap header,

...and a bit more like CommView NCF files, which we already support.

> One way to handle it would be to convert their info to a standard
> radiotap header but it looks kind of complicated to handle that.
> 
> Another approach might be to use a new or different WTAP type and
> write a separate dissector for those headers.

The way to do it, currently, is the same way it's done for NCF - fill in the pseudo-header in the wiretap module, and use WTAP_ENCAP_IEEE_802_11_WITH_RADIO for Wi-Fi packets.  (There's no per-file encapsulation type for NCF or NCFX, so we use WTAP_ENCAP_PER_PACKET.)

> Any thoughts?

Somebody from Tamosoft mentioned NCFX files to me a while ago, suggesting adding Wireshark support, and I worked on it; I've done a merge request for what I have now:

	https://gitlab.com/wireshark/wireshark/-/merge_requests/2762

Currently, there may be some bits of information that the pseudo-header can't handle; if so, it should be extended to handle them.

The "number of streams" is NSS (N sub SS) minus 1 for HT, VHT, and HE PHYs - 0 means 1 stream.

We may want to change the 802.11 pseudo-header to have data rates in units of 100 Kb/s rather than 500 Kb/s, to handle NCFX and possibly other files.  (We might also want to add support for "scaled integer" fields, which display not as the raw value but as the value multiplied by/divided by a scaling factor, if avoiding inaccuracies due to scaling values not being representable exactly as floating-point binary numbers (.5 can, .1 can't).