Wireshark-dev: Re: [Wireshark-dev] Writing a wtap module for CommView WLAN Analyzer and Decoder
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).
