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
I’m happy to announce that Tcpreplay 3.4.0 is out and posted to
Sourceforge. This is a pretty large release in terms of bugs fixed
and enhancements so here’s the changelog:
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
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
- Fix timesdiv() timer code (#332)
- Improve high-performance packet sending via multiple
- 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
Oh, and here’s the download link:
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!
For some reason, probably due to a sever mental defect, I actually enjoy writing C code. Yes, there are plenty of other languages which have plenty of aspects which are better then C, but I just don’t find any of them as satisfying to actually write code in. Ruby comes the closest, but as languages go, it’s still a little wet behind the ears while C is mature. What does that mean? I’ve been working on tcpreplay again- even after I claimed I was putting it away for the foreseeable future. Continue reading
I figured I’d write a quick situation report on the three open source projects I’m involved with:
- Tcpreplay Pretty much in total maintenance mode right now. I’m more then happy to help users and fix any bugs which people report, but I’m not working on any new features right now.
- OpenPacket Looks like OpenPacket is in the process of being restarted and is going to move from Ruby on Rails to PHP. My last experience with PHP (about 7 years ago) was enough to make me swear it off and I’m just not interested in re-learning it again. Hence, I suspect my role will be limited to providing suggestions for the team.
- Cabernet Due to the move & my vacation to the Yukon/BC/Alaska, development has definitely slowed down, but now that things are getting back to normal I’m expecting to get some more work done. One thing I’m considering is starting a rewrite. Cabernet was my very first RoR application and I’ve definitely learned a lot and there are a lot of new and interesting plugins out there which are quite interesting.
The other option is working on the UI. There are still a lot of things which need work (especially adding bottles and searching) which I don’t think would need a complete rewrite. I still need to decide what Cabernet should become- a OSS application for end users or a hosted solution (which seems to be the norm for the wine drinking community).
With the upcoming move, we’ll have to unload & reload our wine collection from the wine cabinet. For some people that may not be a big deal, but when you’re dealing with a few hundred bottles being tracked in a database, it’s important that all the bottles go back to their original location after the move. Hence I’ve been looking at generating a printable inventory that we can take with us for the move. As you may know, printing web pages doesn’t always give the expected results, so I’ve been playing with generating PDF files. Continue reading