2 Bugs, Feature Requests, and Patches

2.1 Where can I get help, report bugs or contact the developers?

The best place to get help or report a bug is the Tcpreplay-Users mailing list:
http://lists.sourceforge.net/lists/listinfo/tcpreplay-users

2.2 What information should I provide when I report a bug?

One of the most frustrating things for any developer trying to help a user with a problem is not enough information. Please be sure to include at minimum the following information, however any additional information you feel may be helpful will be appreciated.

• Version information (output of -V)
• Command line used (options and arguments)
• Platform (Red Hat Linux 9 on Intel, Solaris 7 on SPARC, etc)
• Error message (if available) and/or description of problem
• If possible, attach the pcap file used (compressed with bzip2 or gzip preferred)
• The core dump or backtrace if available

2.3 I have a feature request, what should I do?

Let us know! Many of the features exist today because users like you asked for them. To make a feature request, you can either email the tcpreplay-users mailing list (see above) or fill out the feature request form on the tcpreplay SourceForge website.

2.4 I've written a patch for tcpreplay, how can I submit it?

I'm always willing to include new features or bug fixes submitted by users. You may email me directly or the tcpreplay-users mailing list. Please do not use the Patch Tracker on the tcpreplay SourceForge web site. But before you start working on adding a feature or fixing a bug in tcpreplay, please make sure you checkout the latest source code from the Subversion repository. Patches against released versions are almost surely not going to apply cleanly if at all.

2.5 Patch requirements

• Be aware that submitting a patch, you are assigning your copyright to me. If this is not acceptable to you, then do not send me the patch! I have people assign their copyright to me to help prevent licensing issues that may crop up in the future.
• Please provide a description of what your patch does!
• Comment your code! I won't use code I can't understand.
• Make sure you are patching a branch that is still being maintained. Generally that means that most recent stable and development branches (2.0 and 3.0 at the time of this writing).
• Make sure you are patching against the most recent release for that branch.
• Please submit your patch in the unified diff format so I can better understand what you're changing.
• Please provide any relevant personal information you'd like listed in the CREDITS file.

Please note that while I'm always interested in patches, I may rewrite some or all of your submission to maintain a consistent coding style.