Getting Help

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

We respond as quickly as possible to support requests. The steps in this section describe the information that Mobileum dsTest 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.

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:

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;

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.

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

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.

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.

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.

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 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.

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

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

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: