Wireshark mailing list archives
Re: Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files
From: Richard Sharpe <realrichardsharpe () gmail com>
Date: Mon, 19 Apr 2021 10:02:18 -0700
On Sun, Apr 18, 2021 at 9:30 PM Guy Harris <gharris () sonic net> wrote:
On Apr 18, 2021, at 2:33 PM, Richard Sharpe <realrichardsharpe () gmail com> 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 (何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files Richard Sharpe (Apr 18)
- Re: Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files Guy Harris (Apr 18)
- Re: Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files Richard Sharpe (Apr 19)
- Re: Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files Guy Harris (Apr 18)