From: Aaron T. <at...@po...> - 2003-11-05 02:28:49
|
Hey Jaykumar, This is a common question for people replaying high-speed captures (or using flags like -R)... I prolly really should add it to the FAQ. Anyways, short version is that it is NOT tcpreplay's fault (well unless you're using -x or -X in which case you told it not to replay all the packets). Basically, the system which is running tcpdump (even when the same system actually sending the packets) isn't able to keep up. It is important to note that just because tcpdump didn't report it didn't drop any packets, doesn't make it true. The tcpdump guys will tell you that it's not uncommon for the kernel to lie about dropping packets in which case tcpdump will repeat that lie. Now of course it's possible that some OS's don't tell tcpreplay that it's send buffer is full and drops the packet on the floor instead of actually sending it. Nothing really can be done about that. I know that Linux 2.4 kernels at least will complain, and tcpreplay will keep retrying to send the packet until the kernel accepts it before going on to the next packet. In such a case, I it's possible that packets would not be sent, but nobody has ever been able to show me that is happening. Feel free to be the first to prove me wrong. :) -Aaron On Tue, Nov 04, 2003 at 05:30:30PM -0800, Jaykumar Gosar wrote: >=20 > Hi all, >=20 > Is it possible that tcpreplay will not send all > packets. I have a captured file and two OpenBSD > machines connected to each other. When I replay the > capture file with tcpreplay at the captured speed > (which is ~70Mbps) from one machine, and I run > 'tcpdump -n > /dev/null' on the other, I sometimes get > less than the sent packets and that too less by > different amounts on different runs. When I play the > traffic at 0.1 the speed (using '-m 0.1' option) I > always get all the packets. >=20 > Any ideas why this could happen. Has it happened to > other people? Is is a known problem? >=20 > Thanks for any help. >=20 > Jaykumar Gosar > Student=20 > Georgia Tech >=20 > PS: I am getting 'write attempts failed ...' message > when I replay it at capture speed and not with '-m > 0.1', but that shouldn't matter right? |