04/9/12

Need help with tcpreplay? Read this!

I’ve noticed a certain pattern come up more and more recently and so I’d just like to make a public statement about asking for help with using tcpreplay:

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

08/22/10

Why Tcpreplay went GPL

I’ve been thinking about this for a while and honestly pretty made up my mind months ago, but I finally go enough determination to edit almost all the files in the trunk source tree and change the license from the 3 clause BSD to GPLv3.

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

08/15/10

tcpreplay 3.4.5 beta1 released

Just a quick heads up for everyone, I’ve released tcpreplay 3.4.5
beta1beta2: https://synfin.net/tcpreplay-3.4.5beta2.tar.gz

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!

03/18/09

Rejected!

As I expected, Tcpreplay was not accepted for the Google Summer of Code. Most likely because compared to many of the other mentoring organization applicants, Tcpreplay is not able to accept many students- hence the overhead is too high.

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.

03/12/09

GSoC 2009

Well I decided to throw my hat into the ring for being a mentoring organization for the 2009 Google Summer of Code for Tcpreplay. Obviously Tcpreplay will be one of the smallest “organizations” to submit an application so I can’t say that I have high hopes of being accepted, but I figured it was worth a try. Continue reading

01/21/09

Tcpreplay 4.0 devel has started…

OK, I have to admit- priorities have really changed for the next major Tcpreplay release. You can thank (or I guess depending on your perspective, blame) Abdel Younes who has stepped up and offered to create a GUI for Tcpreplay. Honestly, if it wasn’t for Abdel I’m not really sure I’d even be working on the next major release. Continue reading

01/8/09

Tcpreplay 3.4.0pre2 available

This is the second pre-release of 3.4.0 which I hope to have out in
the next week or two. There’s a lot of bug fixes and improvements
(mostly related to performance) and a few major changes. The biggest
change is completely removing libnet as an (optional) dependancy from
Tcpreplay. As any long-time subscriber to tcpreplay-users knows, I’ve
had a love-hate relationship with libnet, and I’m thrilled to replace
it with libdnet which seems to have fewer bugs and is still being
maintained. Libdnet is also required for fragroute support in
tcprewrite, so this should reduce the number of dependencies some
platforms have.

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!