I’m happy to announce that I’ve used tcpreplay to send packets under WinXP/Cygwin. I have to say, the port has gone a lot smoother then I expected. I’d guess that getting basic functionality working was probably about 25-50 lines of code (most of that GNU Autoconf). While I have run into a few problems that I’m not sure yet how to resolve, things are actually going quite well so I’ve moved up Win32 support to 3.0.RC1. If anyone is familiar with creating an installer for Win32 (MSI or something like that???) I’d love to hear from you.

So I was looking at the tcpreplay download statistics and I made a very unexpected realization: roughly 30% of the downloads in the last 12 months were for the Windows version. Continue reading →

I’m happy to announce that 3.0.beta12 is finally out. This is a pretty important release because of the extensive changes to how different DLT/Layer2’s are supported in tcprewrite. In the past it was a big block of monolithic code which as many of you know had some serious bugs and limitations. 3.0.beta12 moves to a full plugin based architecture which makes adding support for various DLT’s very easy. Continue reading →

Thanks to Hewlett-Packard’s Linux Expertise Center, I’ve been able to make IA-64 binaries available for tcpreplay 2.3.5. Please note that these binaries were provided by HP and neither I nor any of the tcpreplay contributors support them. Furthermore, I seriously doubt that HP supports them either, but then again I didn’t ask.

I was just browsing SourceForge and noticed that they seem to have (finally) fixed the project stats. Anyways, I decided to check out the tcpreplay stats for the last two months. Did the math and people are downloading tcpreplay 40.9 times on average per day. Wow. Honestly, I didn’t think there were close to that many people downloading the source code… after all most people can get tcpreplay from BSD ports, RPM or the like.

Anyways, short status update. I had hoped to work on tcpreplay over the holidays last month, but was too burnt out to do any coding. Hopefully I’ll be able to find some time soon to continue the work on the DLT plugins. On a side note, I found someone else is working on a similar suite: Bit-Twist. Looks like he’s made some good progress in under a year.

Just got an email from Freshmeat saying that they’ve de-listed the libnet library from their database. Sure enough, www.packetfactory.net is offline. Anyways, I’ve emailed Mike to see what’s going on. Until then I’ve uploaded my last copy of the source code to here: libnet-1.1.3-RC-01.tar.gz

UPDATE: The email to Mike bounced and the libnet mailing list has been basically dead for over a year. Starting to smell like abandon-ware. Also, I could of sworn libnet-ng had an actual web page, but looks like that was taken offline or I was horribly confused.

So one of the tcpreplay users has pointed out that it sometimes it doesn’t send the entire packet. I thought this was very odd since tcpreplay is actually quite simple relatively speaking so there’s not much room for bugs like this to sneak in. After some research I figured out the problem was a broken pcap capture file.

Specifically:
The libpcap specification stores multiple instances of the packet length:

1. Maximum stored packet size per file (snaplen)
2. Original packet size per packet (len)
3. Stored packet size per packet (caplen)

The issue becomes when the snaplen is less then the caplen. This shouldn’t happen, but it may due to bugs in code. The result is that the libpcap library lies and returns the lesser of the two numbers (snaplen) and truncates the packet- even though libpcap advances the file descriptor caplen bytes. This clearly violates Postel’s Law.

Of course the maximum stored packet size is rather redundant- no reason you couldn’t pick a reasonable default buffer size (say 65535 bytes) and realloc the buffer if the stored packet size is larger then that. But libpcap doesn’t do that, and doesn’t provide an API to let you know that this is happening. The result is that tcpreplay only has access to incorrect information and fails to send the entire packet.

I’m currently working on the libtcpedit DLT plugin support. The major goals are:
1. Make it easy to add support for new DLT types in the future.
2. Support the top 3 or 4 most commonly used DLT types out of the box for 3.0.

With that in mind, I’m requesting people let me know what DLT types other then Ethernet they work with the most. Some DLT’s to think about are: Linux SLL (cooked socket), BSD Raw IP, NULL, FDDI, PPP, Cisco HDLC, Prisim, Aironet, IEEE802.11 and IEEE802.11 w/ radio header.

So far I’ve got votes for:
– Cisco HDLC
– Linux SLL
– “the most common WiFi DLT types under Linux” (anyone know which that might be?)

When you vote, please vote for a #1 priority, #2 priority, etc. Just rattling off a bunch of DLT’s isn’t all that useful to me.

For a full list of libpcap DLT types check here.