Cannot open CommView for Wi-Fi 6.3.0.683 trace files

This issue was migrated from bug 5509 in our old bug tracker.

Original bug information:

Reporter: Tyson Key
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: Git

Attachments:

Beacons_1.ncf: A trace file containing some management frames, in CommView format
Beacons_2.ncf: Another trace file containing management frames, in CommView format.
Bitrate_tests.ncf: Frames for bitrate algorithm testing

Tyson Key said:

Build Information: Version 1.5.0-SVN-35216 (SVN Rev 35216 from /trunk)

Copyright 1998-2010 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.16.6, with GLib 2.24.2, with WinPcap (version unknown), with libz 1.2.3, without POSIX capabilities, without libpcre, without SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.8.5, with Gcrypt 1.4.5, without Kerberos, with GeoIP, with PortAudio V19-devel (built Dec 17 2010), with AirPcap.

Running on 64-bit Windows 7, build 7600, with WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

It appears that TamoSoft have quietly updated the file format used for 802.11 trace files since support for them was added to Wireshark (in Bug #1795).

Files generated with the latest version of the "CommView for Wi-Fi" product seem to have a different (dynamic?) magic number to older files; and having had a brief look at the specification (at http://www.tamos.com/htmlhelp/commview/logformat.htm), I can't easily determine what they've changed - although the 802.11n, SuperG and Public Safety flag values look new to me.

I'll attach some trace files shortly.

added uigtk versiondev labels

Tyson Key said:

Created attachment 5642 A trace file containing some management frames, in CommView format

Tyson Key said:

Created attachment 5643 Another trace file containing management frames, in CommView format.

Stephen Fisher said:

Thanks for the report.  When I wrote the commview code for Wireshark, I made the heuristics to see if it is a commview file very specific (perhaps too specific) as you can see from this code snippet from wiretap/commview.c:

	/* If any of these fields do not match what we expect, bail out. */
	if(cv_hdr.version != 0 ||
	   cv_hdr.year < 1970 || cv_hdr.year >= 2038 ||
	   cv_hdr.month < 1 || cv_hdr.month > 12 ||
	   cv_hdr.day < 1 || cv_hdr.day > 31 ||
	   cv_hdr.hours > 23 ||
	   cv_hdr.minutes > 59 ||
	   cv_hdr.seconds > 60 ||
	   cv_hdr.signal_level > 100 ||
	   (cv_hdr.direction != 0x00 && cv_hdr.direction != 0x01 &&
	    cv_hdr.direction != 0x02) ||
	   (cv_hdr.flags & FLAGS_RESERVED) != 0 ||
	   ((cv_hdr.flags & FLAGS_MEDIUM) != MEDIUM_ETHERNET &&
	    (cv_hdr.flags & FLAGS_MEDIUM) != MEDIUM_WIFI &&
	    (cv_hdr.flags & FLAGS_MEDIUM) != MEDIUM_TOKEN_RING) ||
	   cv_hdr.reserved != 0)
		return 0; /* Not our kind of file */

I'll see if I can spot the change with a hex editor.

Stephen Fisher said:

They started using the final 2 bytes of the 24 byte header that was previously reserved (back in 2007 when I wrote the wiretap code), and I'm checking to make sure the reserved bytes are set to 0 per the old specification. I'll commit a fix for this.

Stephen Fisher said:

I've made the basic changes necessary to read your capture files:

- Change existing signal_level variable to signal_level_percent

- Add a comment on the new use for the direction variable when using WiFi and stop checking to make sure it is 0x01 - 0x03

- Read and write the two new fields that were reserved: signal_level_dbm and noise_level

The new variables aren't used by Wireshark though (not sure if they can be with the existing dissectors).  So the signal_level_dbm and noise_level are set to zero when writing a commview file out and ignored when reading in.

This is available as of SVN revision 35234.  I see that you're already running an SVN version of Wireshark for Windows, and the new one (35234 or higher) should be available within a few hours.

Stephen Fisher said:

(In reply to comment #5)  

> This is available as of SVN revision 35234.  I see that you're already running  
> an SVN version of Wireshark for Windows, and the new one (35234 or higher)  
> should be available within a few hours.  

... from the buildbot.  It's available immediately if you're tracking the code in trunk with Subversion.

Tyson Key said:

Thanks!

Stephen Fisher said:

Tyson,

Can you check to see if the data rate reported in Wireshark's radiotap dissector is correctly read from the commview file? It's saying that the beacon rate is 1.0 Mb/s, but the commview file format states that the rate field is the speed multiplied by 2 whereas Wireshark is just copying it over to the Mb/s field in radiotap.

Tyson Key said:

I'll have to wait until the BuildBot has built a 64-bit Windows installer, since I've been unable to successfully bootstrap a working development previously (I wanted to build a third-party plug-in for Nokia's proprietary ISI protocol, if you're curious).

CommView for Wi-Fi reports the data rate as "1.0 Mbps" for Beacon frames, so the current algorithm is probably correct.

Just in case, I'll post some traces containing various Data frames, along with reports of what CVWF reckons the per-frame data rate values to be. :)

Tyson Key said:

Created attachment 5645
Frames for bitrate algorithm testing

Here's the trace file containing a number of frames with wildly differing bitrates, as reported by CommView for Wi-Fi:

Frames 1 and 2: "24.0 Mbps"

Frames 3 and 4: "54.0 Mbps"

Frames 5 and 6: "5.5 Mbps"

Frame 7: "48.0 Mbps"

Frame 8: "1.0 Mbps"

Frame 9: "11.0 Mbps"

I hope that they're useful.

Stephen Fisher said:

Perfect, thanks!

I managed to confuse myself reading the Wireshark code -- commview files store the data rate as real rate multiplied by 2. Wireshark stores the rate in the same way (but says "in 0.5 Mb/s units" whereas commview says "multiplied by 2" -- which are of course the same thing) internally and then divides it by 2 for display.

closed