Inline... On Oct 23, 2007 3:30 PM, James Bergeron <[EMAIL PROTECTED]> wrote: > Hi, > > I seem to have a problem where as sometimes packet 2 is sent before > packet 1. Or they are sent so close in time to each other my DUT sees > packet 2 before packet 1. This only occurs on older versions of linux > for some reason, and only when packet 1 is sent on eth1 and packet 2 on > eth2.
Quite possible if the packet timings are very close and the kernel on the box running tcpreplay decides for some reason to service the 2nd packet first. > I was looking at making a minor modification to tcpreplay for my > purposes that would count the number of packets sent on eth1 and expect > them on eth2 before sending any packets on eth2. Yes I know it sounds > stateful and sounds like Tomahawk but tomahawk does some very odd stuff > that does not work in my environment. Tcpreplay works perfect for me > except for this odd case and only when timing is just right (or wrong). > I have tried slowing things down with the -p option but that does not > solve the problem. I have slowed things down with a static delay > between packets and that does work. If the -p option doesn't work for you, I suggest you look at the pcap in wireshark and take a close look at the packet timestamps in the libpcap packet header. I've lost count the number of times I've seen timestamps go backwards in time which would always cause an immediate write of the 2nd packet when using -p. > What I would like to do is count the # packets going out each ethernet > device and decrement this counter when packets enter the other ethernet > device (-i and -j). Allowing sending to only occur when the counter is > zero. Does tcpreplay current monitor the ethernet stack for ingress? > I'm not sure where to start here and any guidance would be appreciated. > It seems fairly simple on the surface. I'm going to make you scream > more when I say I'm using version 2.3.5 because it does everything I > need :P Unless you think upgrading to 3.0 or 3.1 will solve the current > problem I have. I won't scream, but I won't be back porting such a feature to the 2.x series either. :) Your feature request is a little more difficult then you describe since so many devices will generate their own packets (ARP requests in order to resolve MAC addresses in order to forward packets is pretty common) and of course there may be other traffic flowing or even multiple copies of tcpreplay running. Anyways, you're not the first person to have this problem and likely not the last so I'll add this to my ever growing to-do list. :) If you can write C, contact me offline and I'll try to point you in the right direction. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Tcpreplay-users mailing list Tcpreplay-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
