Advanced Topics

Capturing High Volume Traffic

When capturing data from a large and busy network segment, you should keep in mind that processing thousands of packets per second may considerably increase the CPU usage and make the application less responsive. The best way to optimize the program's performance is to use rules to filter out the packets you don't need to monitor. For example, sending a 50 MB file between two machines on your LAN can generate approximately 40,000 NetBIOS packets with the data transfer rate of 10 MBytes per second, which can be a heavy load for the application. But normally you don't to need to view every NetBIOS packet being sent, so you can configure CommView to capture IP packets only. CommView has a flexible system of filters, and you can fine-tune the application to display only the packets that you really need. Also, if you are interested in the statistics information only (those green histograms, pie charts, and hosts tables), you can use the "Suspend packet output" menu command, which allows you to have statistical data without real-time packet display.

The factors that improve the program's performance:

• A fast CPU (Intel Core i7 is recommended)
• RAM size (8 GB and higher recommended)
• Using rules to filter out unnecessary traffic

Working with Multiple Instances

CommView can capture packets from several network adapters simultaneously. This feature is turned on by checking the Allow Multiple Application Instances checkbox in Settings => Options => Miscellaneous. Please note that you cannot open the same adapter in two different instances of the program. The same limitation applies to the Terminal Server: two users (local or remote) cannot capture traffic from the same adapter by running two instances of CommView on the same server.

Running CommView in Invisible Mode

There are two ways to run CommView as a hidden process:

1. Launch CommView with the "hidden" switch, i.e.:
   CV.EXE hidden
2. If CommView is already running, you can hide/unhide it by using the "hot key". To hide the application, press ALT+SHIFT+h. To unhide the application, press ALT+SHIFT+u.

Remember that you cannot completely hide any Windows application. When running in invisible mode, one can still see the CommView process in Task Manager.

Command Line Parameters

You can use command line parameters to perform the following operations when the program is being launched:

• Load and activate a rule set from a file. Use the "/ruleset" switch followed by the file name and full path, e.g.:
  CV.EXE /ruleset "C:\Program Files\CommView\Rules\POP3Rules.rls"

  If a file name or its path contains spaces, it must be enclosed in quotation marks (" ").

• Open an adapter and start capturing. Use the "/adapter" switch followed by the adapter name, e.g.:
  CV.EXE /adapter "Intel(R) PRO/1000 T Desktop Adapter"

  The adapter name must be enclosed in quotation marks (" "). Since adapter names are typically long, you might want to copy the adapter name from the program's adapter selection box rather than type it. To copy the adapter name, select the adapter in the adapter selection box and press Ctrl-C.

• Use the specified folder for storing log files. Use the /logdir switch followed by the full path to the folder, e.g.
  CV.EXE /logdir "C:\Program Files\CommView\Logs"
• Connect to one or several remote agents. Use the "/ra" switch followed by the IP address or hostname of the Remote Agent you'd like to connect to, followed by the password in quotation marks, followed by the adapter number that should be monitored (the adapter index is 1-based, i.e. if you need to monitor the first adapter, use "1"), e.g:
  CV.exe /ra 192.168.0.5 "MyPassword" 1

To connect to multiple Remote Agents from the same CommView instance, first make sure that multiple CommView instances are not allowed in the application options, and then use a batch file that should look like this:

This script launches CommView, waits for 5 seconds to make sure that the application is loaded (we use the PING command to pause because there is no direct way of telling a .BAT file to pause), then we pass to the application the IP addresses, passwords, and adapter numbers of three Remote Agents (with one-second pauses).

You can use all of these parameters, except the last one, at the same time.

Exchanging Data with Your Application

CommView provides a simple TCP/IP interface that allows you to process packets captured by CommView using your own application in real time. Starting with version 5.0 you may also use this interface for sending packets (similar to the Packet Generator function in CommView).

Please note that the data format has changed compared to the previous versions of CommView. The TS switch has also been eliminated as all the information about a packet including the timestamp is now sent in the header.

How It Works

CommView should be launched with a special command-line argument, "MIRROR", that tells the program to mirror captured packets to an IP address and TCP port of your choice.

Examples:

When CommView is launched with a switch like this, it tries to establish a TCP session by connecting to the specified IP address and port number. It means that you should already have your application running and listening on the specified port. If CommView fails to establish a connection, it will keep on trying to connect every 15 seconds. The same happens if the connection is broken: CommView will try to re-establish it every 15 seconds. If the connection is successfully established, CommView sends the packets it captures to the specified IP address as they arrive, in real time.

Data Format

The data is transmitted in NCF format. Please refer to the CommView Log Files Format chapter for the format description.

Sending Packets

Packets may not only be received by your application, but also sent as if you were using Packet Generator. Data can be sent to CommView using the same TCP connection over which you are receiving the data. The data format is simple: You should send the packet length (a two-byte unsigned integer in the standard little-endian byte order) followed by the packet itself. If the adapter is not opened or it does not support packet injection, the packet is silently discarded.

Sample Projects

Two simple demo applications that listen for inbound connections, extract packets from the stream, and display raw data are available.

• https://www.tamos.com/products/commview/samp_mirr_c5.zip. This is a Visual Studio project with C++ source code.
• https://www.tamos.com/products/commview/samp_mirr_d5.zip. This is a Delphi project with Pascal source code. If you want to compile the project, you'll need the popular ICS components suite by Francois Piette, available at https://www.overbyte.be.

Bandwidth

When mirroring data to a remote computer, make sure that the link between CommView and the computer to which the data is being mirrored is fast enough to transfer all the data being captured. If CommView captures 500 Kbytes/sec, and your link can handle only 50 Kbytes/sec, you'd inevitably have "traffic jams", which might result in various problems (e.g., Winsock may just stop sending data under some Windows versions). If you are looking for a more flexible solution that would feature smart buffering and remote control, consider using CommView Remote Agent.

Custom Decoding

CommView allows you to use two types of your own custom decoders.

Simple Decoder

If you implement this type of decoder, the output of your decoder will be displayed in the additional column in the Packets tab. Your decoder must be a 32-bit DLL file named "Custom.dll" that exports the only procedure named "Decode". The prototype of this procedure is shown below in C and Pascal:

The DLL must be located in the CommView application folder. When you launch CommView, it looks for "Custom.dll" in the application folder and loads it into memory. If the "Decode" entry point is found, CommView adds a new column named "Custom" to the packet list.

When a new packet is captured and is about to be displayed, CommView calls the "Decode" procedure and passes the packet contents to the DLL. The "Decode" procedure must process the packet data and copy the result to the supplied buffer. The first argument is the pointer to the packet data, the second argument is the data length, the third argument is the pointer to the buffer where the results of your decoding must be copied to, and the forth argument is the buffer size (currently always 1024 bytes). The buffer is allocated and freed by CommView, so don't attempt to reallocate or free it. The result that you copied to the buffer will be displayed as a string in the "Custom" column.

Your procedure must be fast enough to handle thousands of packets per second; otherwise it may slow down the application. Don't forget to use the STDCALL calling convention.

Two demo DLLs are available. They demonstrate a very simple operation: The output of the "Decode" function is the hex code of the packet's last byte. Your own decoder can be as complex as you wish.

• https://www.tamos.com/products/commview/cust_decoder_c.zip. This is a Visual Studio project with C++ source code.
• https://www.tamos.com/products/commview/cust_decoder_d.zip . This is a Delphi project with Pascal source code.

Complex Decoder

If you implement this type of decoder, the output of your decoder will be displayed as additional items in the packet decoder tree. For information on the implementation of this decoder, please download the following file:

https://www.tamos.com/products/commview/complex_decoder_c7.zip

This type of decoder can be written in Microsoft Visual C++ only, as it is built using C++ classes.

Technical Support

Technical support for custom decoders is provided on the "best effort" basis. We may not be able to answer your programming-related questions.

CommView Log Files Format

CommView and CommView for WiFi use the data format described below for writing captured packets to .NCF files. This is an open data format that you can use for processing log files generated by CommView in your applications, as well as for exchanging data with your application directly (this method is described in this help file).

The packets are recorded consecutively. A 24-byte header, the structure of which is given below, prepends each packet body. All header fields with the length exceeding 1 byte use little-endian byte order.

The total header length is 24 bytes.

If packets are stored in the compressed form, the Data Length field contains the length of data after compression, whilst the Source Length field contains the original data length. If a packet is uncompressed, both fields contain the same value.