Getting Help

Our Help Desk is available Monday-Friday between 8:00 AM and 5:00 PM U.S. Central Time.

Phone: 877-233-8350 ext. 2

Reporting An Issue

We respond as quickly as possible to support requests.  The steps in this section describe the information that Developing Solutions Support needs to successfully analyze your reported issue.

A detailed description of the issue is very important and the more information that is provided the more quickly and accurately we can understand the issue. Please make sure to include a description of the test configuration and pointers to specific messages/IEs/AVPs in question and what you believe the issue to be. If you believe dsTest is not meeting the published standard identified in our Specification Map for the specific protocol, please identify the specification and the specific paragraph in question.

By following these steps you will expedite the support process, giving us the information necessary to analyze your issue.

dsTest Issues

These items are required to analyze an issue and provide guidance for dsTest issues:

A concise statement of the issue, with the desired message flow diagram and message contents;

The dsTest Version and Build information - found when the program is first launched or by typing the command version:

dsTest> version

Application: dsTest Version: 2.6.20130523 Build: Wed May 23 16:46:27 2013


ds_log file(s) that span the execution time frame;

ds_log.stderr file

xml or dsx configuration file(s);

message flow(s) capture that span the execution time frame, with pointers to specific messages/packets that you believe to be in error or demonstrate the issue;

om.db file(s) that span the execution time frame- OM files will be in the directory from which you started dsTest;

run time commands being executed from the command line;

core dump file, if applicable;

Any other materials as instructed by Support.

All files should be compressed (tar, zip) into one file so that it can be more easily emailed or uploaded. If compressing/zipping the files in a Windows environment, use a utility that will compress/zip the files in a format that a readily available unzip utility, such as 7zip, can uncompress.

If you are using dsClient Desktop, utilize the Collect Test Results feature as it will collect and package all of the necessary files for Support.

dsClient Desktop Issues

If you are experiencing a dsClient Desktop issue, gather the following information:

A concise statement of the issue, with steps to reproduce

Any screen shots that help to illustrate the issue

Workspace file(s) if applicable (you can use the application's export feature to bundle all pertinent files)

The current client.x.log file, which will either be located in the directory from which the application was executed or, if the application was launched from a web page, in the .dsClient directory within your home directory.

All files should be compressed (tar, zip) into one file so that it can be more easily emailed or uploaded. If compressing/zipping the files in a Windows environment, use a utility that will compress/zip the files in a format that a readily available unzip utility, such as 7zip, can uncompress.

Information To Submit

ds_log Files

The ds_log file is extremely helpful for debugging problems and is therefore required when reporting an issue. The amount of information collected in the log file depends on the current log level. Support may request that the user temporarily change the log level to capture additional information in the ds_log file. See Logging and Log Files for more information on setting the log level and managing log files. The ds_log.stderr file contains console output that may be valuable when investigating a crash. These files are stored in the directory from which dsTest was launched.

Please remember that increasing the log level will impact the performance of the system and must only be done temporarily while debugging or when instructed by Support.

Test Configuration Files

The configuration files allow Support to inspect your configuration for problems as well as to be able to run your file on our test systems to try and reproduce the issue. If you are using dsClient Desktop, these files will have a dsx extention, and will be located in your GUI xml library directory. Use the GUI export feature to bundle all pertinent dsx configuration files, and also include any run-time commands being used.


Message Trace(s)

If you are using dsClient Desktop, use the packet capture feature to capture message trace(s). Alternatively, the dsTest test server can be used to capture message trace(s) using the tcpdump command. If dsTest is running under heavy load it would be best if the traces are collected at another point in the network as test server performance will be impacted. In the description of the issue, please provide specific message/packet numbers that demonstrate the error or issue.

If you are using dsClient Desktop, use the Packet Capture feature, as it will not lose packets.


om.db Files

om.db files contain the Operational Measurements collected by dsTest, and are stored in the directory from which dsTest was launched. The file 'om.db' is always the most current OM file and when filled is rotated to 'om_0.db' and a new om.db file is started. This process continues until the maximum number of files is reached, after which the oldest will be discarded. The maximum number of OM files can be specified when launching dsTest. The OM files will also rotate when dsTest is stopped and restarted. When gathering the OM files, refer to the file time stamp to insure that all pertinent files are gathered. OM files must be closed before transporting. OM files will close when all nodes are deleted, or the CLI command 'diag om close' is executed.


om.db must be closed before it is copied/transported. OM files will close when dsTest is restarted, all nodes are deleted, or the dsClient Terminal command 'diag om close' is executed. Any of these actions will also roll the files, so that om_0.db will be the file of interest. Failure to close om.db before copy and/or transport will cause the file to be corrupted, and maybe be unusable by Support.

Steps to Submit Information to Support

The following steps are required when gathering information to submit to Support:

1.Stop and restart dsTest to close and rotate the ds_log and om.db files;

2.Start a packet capture on the appropriate interfaces;

3.Set the log level to 10;

4.Source the configuration file(s);

5.Run the test at lowest rate and the shortest period of time possible to adequately capture the issue;

6.Stop dsTest;

7.Stop the capture;

8.Gather and compress all .xml/dsx, ds_log, om.db, capture files and any other information requested by Support.

Once you have gathered and compressed all of the files, they can be emailed to Support, or you can log into our SCP server and transfer the files to it directly:

          user: devsol

          password: devsol


Notify Support by phone or email once the files have been transferred.


dsAssist is a customer-initiated utility that allows remote access to the customer system by Support. This utility creates an ssh tunnel between the Support Server and the server that's executing the command. When using dsAssist, you will prompted for a password, supplied to you by Support. Once the password is entered, Support will be able to ssh into the server even if it is behind a firewall. Support will need to be given login and password information in order to use this feature.