Occasionally people are testing some kind of top secret device with tcpreplay and can’t tell me how it works or what it does or share their pcap file (because it has some kind of exploit or something like that I guess), but expect me to help them figure out why it can’t “see” the traffic tcpreplay sends. That’s a lot like asking your car mechanic to fix your car, but you won’t let them look at it because you’ve modified the engine to run on tap water and don’t want the mechanic to figure out your secret. As you might imagine, this is both very frustrating and a huge waste of my time.

Simply put, if you see the traffic in Wireshark or tcpdump, but your device under test can’t see it, then it’s most likely either a) bug in your product, b) you’ve miss-configured tcpreplay or c) you’ve got a bad pcap. You’ve pretty much ruled out a bug in tcpreplay at that point. Hence if you want help with determining if it’s A, B or C you’re going to have to give me your pcap, tell me what your product does and some basics about how it works under the hood. Honestly, I wouldn’t consider any of this at the company secrets level unless you’re hacking directly in kernel-space and are completely avoiding the well known socket API’s, but that’s your call.

Anyways, if you’re unable to tell the whole world on this mailing list the above, then your other option is to hire me as a consultant (for a price) at which point I’d be happy to sign an NDA to keep your secrets and we can work off list. Other then that, your best bet is to try and figure it out on your own, but please don’t ask me or the list for help to your problem.

Thanks,
Aaron

There’s actually a number of reasons for the change and I wanted to share the ones that were most important to me. I don’t expect everyone to like the decision, but probably most won’t care since it doesn’t really impact them. But sometimes people get all bent out of shape when a project that has been around as long as Tcpreplay (10 years? Damn, where did the time go?) changes its license so I wanted to give my side of it. The change doesn’t mean I don’t like the BSD license anymore, just that I now feel the GPL is more appropriate for the Tcpreplay Suite.

First, for those of you not familiar with the GPL and BSD, what this means for 99% of users is everything stays the same. Tcpreplay is still distributed at no cost and the source code is available for you to read, edit and redistribute. You can use Tcpreplay at no cost for personal and commercial use. The only difference is that if you redistribute Tcpreplay, you need to make the source code of Tcpreplay and any code which links to it available to anyone who asks for it. If your code runs as a separate process then you don’t need to share that. There’s no legal requirement for you to proactively send me a copy of your changes, but I would very much appreciate that.

As for why, it comes down to the following reasons:

1. Values. I still want to give Tcpreplay away for others to use and build upon, but it’s been frustrating to hear about people who have added features and then for one reason or another decide they don’t want to share those with the rest of the Tcpreplay users. This willingness to take, but not give back to the community sucks and I’d rather not allow people to continue to do that. I’ve got hundreds of hours of effort in Tcpreplay and I suppose I don’t think it’s “fair” for people to build upon it without sharing back. I’ve not only seen this with Tcpreplay, but other BSD projects- one of my previous employers added an enhancement to fragroute, distributed the new binaries to their customers, but never sent the patches back to the original author. I think my old company would of sent their changes back if the author knew about it/asked, but because there was no legal reason to do so, they never took the 5 minutes to do it.
2. Support. I’ve actually had people enhance Tcpreplay, distribute it to others and then have these users contact me for support. They couldn’t give me the code and I was stuck trying to explain to someone that even though it was my project, I couldn’t help them because I couldn’t fix the bug they were seeing.
3. Future. Tcpreplay will have a library/API in 4.0 and I hope it will become much more useful to other developers. Going GPL helps to protect the main tree from others creating incompatible forks. Yes, anyone can still fork Tcpreplay for their own purposes, but at least this way I can incorporate the good changes if they start distributing it to others. If you want to fork Tcpreplay for your own internal/personal use, go for it- I just want to limit the chances running into your libtcpreplay.so with an incompatible API getting out in the world causing problems for people.
4. Developers. I’ve discussed license choices with other existing and potential Tcpreplay developers and there appears to be a greater level of comfort with the GPL and it seemed that they would be more willing to contribute if their contributions would be GPL’d versus BSD. Honestly, I don’t expect to see a lot more people working on Tcpreplay due to the license change, but every little bit helps.

-Aaron

UPDATE: One thing I wanted to add, I chose the GPLv3 because I believe it affords better protections then v2. If you have an existing GPLv2 application and would like to incorporate any part of the Tcpreplay Suite into it, please contact me to discuss dual-licensing options.

I wasn’t originally planning on doing a beta for 3.4.5, but due to
feature creep it’s taking more time then I thought. Now that I’m done
racing for the summer, hopefully I’ll have more time to fix the
remaining open bugs & enhancements before the fall. It’s my goal that
3.4.5 will be the final 3.x release, with future enhancements being
placed in the 4.0 branch- it’s become too much of a PITA to keep
merging code between the two branches since 4.0 is really nothing like
3.x.

Anyways, this release concentrates on features & bugs users requested
or found. Special thanks goes out to Dmitriy Gerasimov who
submitted a patch for Linux TX_RING support. It’s not yet supported
on all Linux systems, but on those that it does should hopefully see
improved topspeed performance. I’d love what people’s experience is
with this feature- does it help? If so when? The other major feature
is sending two files at the same time- one out each interface. Should
hopefully be useful when replaying traffic captured via network taps.
Both features probably haven’t seen enough testing by me, but
hopefully some people are interested enough by them to try them out
and let me know how well they work.

Obligatory changelog:

08/15/2010 Version 3.4.5beta1
   - First pass at fixing 'make test' on many little-endian systems (#429)
   - Don't try to fragroute non-IPv4/v6 packets so we don't error out (#432)
   - Warn users when processing LINUX_SLL frames w/o an Ethernet source MAC (#434)
   - Initial Linux TX_RING sending support (#435)
   - Update to GNU Autoconf 2.67 (#436)
   - Add tcpcapinfo which dumps information about the pcap header/packets (#437)
   - Add --dualfile support for replaying two files at the same time (#439)
   - Fix bug where --tos=0 didn't do anything (#440)
   - Fix crash when processing CIDR data (#441)

Update: Turns out I forgot to merge the TX_RING support in. 3.4.5beta2 fixes that. Sorry for any confusion!

Of course, if you are a student (or anyone else for that matter) and are interested in working on Tcpreplay and learn about networking, I’m always willing to help people get up to speed on the code and contribute.

Obviously, if Tcpreplay does get accepted, I’m really looking forward to mentoring one or two students just as a lot of other people mentored me in the past. Obviously one of the biggest concerns I have is not trying to bite off more then I can chew and take on too many contributors- that would be pretty disastrous.

Anyways, if you’re a Tcpreplay user and you’d like to help make Tcpreplay better, I am looking for a few users to be pseudo-product managers for various features that students might develop. Mostly this entails being a sounding board for the feature, providing feedback on what would be useful and spending some time being a beta tester before the code is merged into the mainline branch. If you’re interested in helping in this manner, let me know!

In the first episode, I cover compiling Tcpreplay and what configure options affect performance and how to select the best injection method for your operating system. Probably not the most interested topic (I’m sure a lot of people get pre-compiled packages), but it gave me a chance to tackle a simple topic while focusing on the tools and workflow necessary to create the videos.

Depending on feedback, I’ll be doing additional episodes on various aspects of the Tcpreplay suite as well as other related tools and resources I think Tcpreplay users might find interesting. If you have any comments on this episode or suggestions for future episodes let me know!

That said, Tcpreplay 4.0 is going to look a lot different from 3.x. Obviously the biggest change will be a cross-platform native GUI (yes, that means Windows) in QT4. To make that possible though, there are a number of important things that need to change:

• Need to create an API for the GUI to use
• Need to make the code more cross-platform; specifically add native Windows support.
• Completely change the build scripts/infrastructure to support Windows/VC++

Hence, I’ll be working on the back-end requirements to make the GUI possible while Abdel works on the front-end. I’m hoping sometime around mid-year we’ll be able to make the first real release. If you’re interested in helping out or just want to keep track of what’s going on, feel free to join the tcpreplay-devel mailing list.

You might be (but probably aren’t) wondering what this means for Cabernet… Well I’ll be honest, it means the first release will be delayed even further.

This is in effect the same code as 3.4.0pre3 so if you’ve already
updated, no reason to re-download. There are really only two issues
I’m currently aware of:

1) Doesn’t build with the Sun compiler
2) Packet injection doesn’t use the method documented, but rather the
one listed via: tcpreplay -V. This basically means unless you specify
something like –enable-force-pf (for Linux) or –enable-force-bpf
(for *BSD) you’re probably using something like libpcap or libdnet
which isn’t as efficient. It’s a very slight performance hit, so most
people won’t even notice.

Grab it here.

Now I’m switching gears and I’m starting to work on Tcpreplay 4.0 with
Abdelrazak Younes. Abdel has offered to create a cross platform QT
GUI for Tcpreplay and so I’m working on the backend to make this
possible. I’m really excited to have an experienced GUI developer
like Abdel helping out to make Tcpreplay easier for people to use.

High-speed performance has also been improved via the new —pps-multi
option which allows sending multiple packets at a time without
sleeping in packets/sec mode.

Here’s the current changelog of what’s new in pre2 since 3.3.2:

• Add libdnet and remove libnet support for sending packets (#302)
• Fix numerous 802.11 decoder bugs (#325)
• Fix compile issue under Linux (#326)
• Fix Mbps/sec nonsense (#327)
• Fix tcprewrite crash when packets have no L3+ data (#328)
• Clean up err.c/err.h code and improve performance for non-debug
  builds (#331)
• Fix timesdiv() timer code (#332)
• Improve high-performance packet sending via multiple
  packets/interval (#334)
• Fix statistics report errors (#335)
• Fix BPF filters not being used in tcpbridge (#336)
• Fix autotools usage errors (#340)
• Clean up ‘make test’ results (#341)
• Update to AutoGen/AutoOpts 5.9.7 (#342)
• Fix compiler warnings from GCC 4.2 (#344)
• Fix numerous memory corruption bugs in libtcpedit DLT plugin code (#345)
• Add support for editing IPv4 TOS/DiffServ/ECN (#348)
• Update autotools to more recent versions (#349)
• Report injection method via -V (#352)
• Fix DLT_USER l2len check bug (#353)

There are still some open 3.4.0 tickets for tcpbridge.

It would be great for people to kick the tires so-to-speak and report
any bugs so that I can fix them in time for the official 3.4.0
release.

Oh, and here’s the download link:

http://tcpreplay.synfin.net/tcpreplay-3.4.0pre2.tar.gz

Enjoy!