Wireshark-dev: Re: [Wireshark-dev] Writing a wtap module for CommView WLAN Analyzer and Decoder
On Sun, Apr 18, 2021 at 9:30 PM Guy Harris <gharris@xxxxxxxxx> wrote:
>
> 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).
I think the problem will be that the radiotap HE and other headers
support much more info than what you have suggested.
Will we also add things like GI, LFT symbol size, # LTF symbols, Pre
FEC padding, etc, to the pseudo-header?
In addition, radiotap now supports TLVs (since they ran out of bits in
the features word). However, that is possibly easier to handle, since
an unknown TLV can simply be displayed as raw bytes.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
