Hi Aaron,
I understand the concern for the further complexity -- but -- in my case
for which I am using your software, I do not see ARPs and I am using
dedicated ethernet devices to send and receive traffic. For me, simply
counting would actually work. :)
I can write C, or have many people at my immediate disposal that can
help me write C if need be.
For now, I have stuck a usleep(100000); right before processing a
packet, right in do_packet.c seems to work for me but slows everything
down considerably and without good reason.
What I need guidance on is which data structures contain the information
about which ethernet port is being used and how to monitor the ports for
ingress data.
Thanks!
Aaron Turner wrote:
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.
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
