Wireshark · Ethereal-users: RE: [Ethereal-users] retransmission of captured packetes

["McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>]

I will attempt to help.

-----Original Message-----
From: Bernard, Kurt A. [mailto:KABERNARD@xxxxxxxxxxxx]
Sent: Tuesday, June 05, 2001 2:40 PM
To: 'ethereal-users@xxxxxxxxxxxx'
Subject: [Ethereal-users] retransmission of captured packetes


Hi, I would like to do some testing with the packets I capture on my network
which has multiple segments seperated by routers.  But I'm not sure what
would happen in the following situations:
 
A.  If I put a collection unit on each segment and collect packets for 24
hours, and later retransmit the packets collected, will the routers forward
the packets?  I assume the following set of test conditions for this test: I
would need to reset the time on all routers and synch them to the ms; I
would have to synch the times of all the collection/retransmission systems
to the routers down to the ms;  I would have to throttle transmission rates
and coordinate start/stop transmission times.

No.  You're making life too hard on yourself, in some ways, and forgetting a
couple of things.
 
First of all, you wouldn't have to change the routers at all.  They don't
know anything about the time a packet was forwarded, and there's no such
timestamp in the packets themselves.  If the packets are built correctly,
the routers will forward them.
 
The thing that may get you is this.  Only packets that come *from* the
subnet where you're capturing (or pass *through* it) will replay in a way
you expect.  Packets going *to* the subnet where the ethereal box is won't
go anywhere, except to the destination host.  They're already at the "end".
 
Think of it from a layer *2* perspective and it will make more sense to you.
 
But you won't have to reconfigure any routers at all.  You may have to mess
with your firewall, if it sits in the data path, but not a router.
 
Second, it sounds like what you want to do is simulate a *connection*, not
just a packet stream.  That *would* require time synchronization and some
other complex things, and you're not going to get that with ethereal.  What
you need is more like Chariot.  See http://www.netiq.com
<http://www.netiq.com>  and poke around.  They have software that can
simulate real network traffic.  It's expensive though.

I figure i'll use something like replay to send the packets again...but that
may not be enough...dont know if replay will send at rate packets were
received at.  Anyone know of another app I can use that does send at the
rate received?  I tried NG Sniffer but it cant open large files without
croaking and I cannot determine if the packets are trasmitted at the rate
received or not.

 
Ethereal won't do this (I think), but tcpreplay will do *most* of that.  You
can specify a data rate at which to send out the packets, up to the limits
of what the machine/interface can transmit.
 
With *really* good time synch (and some fast machines), you *might* get
tcpreplay  to regenerate some streams the way you're looking for.  Tcpreplay
allows you to specify that the stream should be sent at m times the data
rate at which it was recorded.  Make m = 1 and you've got it.  The trick is
getting both endpoints to start at *exactly* the same time.  NTP could help
you accomplish this, although you'd probably better have two *identical*
machines at each end.  

 
B.  If I upgrade to GIGE on the network and upgrade my collection unit's
hardware, can ethereal handle the capture and analysis?

 
Ethereal (and Sniffer, for that matter) is just software.  It's capabilities
are largely dependent upon the hardware (and drivers) underneath.  If your
GigE card doesn't support promiscuous mode, for example, you won't get
everything (remember that sometimes even unicast frames are flooded to all
ports in a switched VLAN).  If the driver doesn't pass all of the frame up
to Ethereal, some things will be missing.  The most common example here is
the FCS portion of the frame.
 
Furthermore, depending upon the network load, you'll need a *hell* of a box
to record data that fast, and a *LOT* of memory to buffer it all up.  A GHz
P-III has the processing power and the bus, but what about memory access
times?  What about hard drive access times (*hideous*)?  What about other
processes that need CPU time?  And on and on...
 
Bottom line:  Ethereal can do it, if the hardware can do it.  There's
nothing about GigE that Ethereal can't handle.

Any help or ideas will be greatyly appreciated.
 
Kurt 

 
If you're even going to go up past 100Mb of true throughput, I recommend at
*least* a 1GHz P-III and 512MB RAM on the capturing box.  I have this in my
network now.  Under Linux's 2.4.x kernel (only!  2.2.x didn't work!) it can
handle the load... barely.  At that rate packets are flying by at better
than 20000pps, so buffer space fills up *quite* *quickly*.  I tried with
slower machines for a while, but all they did was crash under the load of so
many interrupts.
 
--J