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/14/09

Stopping wordpress spam bots

I was having a big problem for a few months with spam bots registering user accounts on my blog. Generally, the bots would register accounts assuming (incorrectly) my anti-spam software was more likely to let their comments if they came from a registered account. As you might imagine, this gets pretty annoying pretty quickly. 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!

01/1/09

2008: Tcpreplay

As I put 2008 behind me and look forward to 2009, I wanted to take a look at where Tcpreplay is and where it’s going.

This year there were 5 releases- most of which happened in the first half of the year. Between other projects like Cabernet, working at a startup, buying a new home and trying to sell our townhouse things definitely slowed down the last 6 months or so. But I think there’s also a sense at least on my part that Tcpreplay isn’t really lacking any major features; at least I’m not getting any real feature requests except for something like flowreplay– which I have no interest in working on.

Most of the work that happened revolved around improving the accuracy of packet timings and adding fragroute support. Windows support has improved quite a bit; but isn’t as good as it should be considering the number of Windows users.

Honestly, Windows support continues to be a thorn in my side, but I’m really not sure how to get over the hump so to speak. My development environment is Windows XP under Parallels on OS X which while functional is painfully slow and seems buggy. I’m not sure how much is Parallels fault and how much should be attributed to Cygwin, but end users don’t seem to complain about performance so I guess it must be Parallels. Unfortunately, this makes my development efforts far more painful then they should be and the result is that I don’t work on it as much as I should. I’m sure if I had a dedicated Windows box that would help, but it makes no sense financially for me to go out and by another computer merely for Tcpreplay development on Windows. Ideally, Windows support would be native and not require Cygwin which seems to add a bunch problems… perhaps if I had a dedicated Windows box I’d ship binaries for it- that might actually make sense. Of course all this wishful thinking as I seriously doubt a Windows computer is going to fall from the sky and into my lap for all this to happen.

Next year I hope to release 3.4 which should continue to improve performance and add features which allow people to better visualize the traffic in pcap files so that using tools like tcprewrite and tcpprep is easier. I’m a little surprised people aren’t more excited about the visualization feature, but maybe it’s the kind of feature you have to see in order to understand its value.

On a side note, I’ve been pleasantly surprised with the number of user contributed patches. Most of these are small, but important bug fixes for cross-platform issues which are difficult for me to reproduce and therefore fix on my own. A big thanks to everyone who contributed!