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

Actually, we're *about* to do the same thing.  I posted some stuff about this to the list earlier this week.  :-)

Fortunately, we're going to be monitoring less traffic than you are (~150Mb/s altogether), so what we decided to do was use a port mirror rather than an optical tap.

Many switches can perform port mirroring (I think Cisco calls it "port spanning"), where all traffic into or out of a port gets copied to another port.  Thus your two data streams are automatically multiplexed onto a single RX link, which you can feed into a single GigE NIC.

In your case, you have 640Mb of total traffic, which is <1Gb, so you have the bandwidth.  Can your system keep up with a single device pulling that much data?  If not, how does splitting the streams into two GigE NICs help?  Lastly, out of curiosity, what platform did you use to build this?  I'd be happy to post the specs of our capture box when I'm in the office next (I'm at home and the specs are on my desk).

Anyway, the problem with mergecap is that with any two given files in two ring buffers, the times can get out of sync.  Mergecap will make sure that you never see replies before transmits, because:

"Packets from the input files are merged in chronological order based on each frame's timestamp, unless the -a flag is specified.  Mergecap assumes that frames within a single capture file are already stored in chronological order."

So if you store the full date/time in the timestamp, you'll always get the packets in the right order, but you might see replies in the receive stream from stuff that happened many thousands of frames ago in the transmit stream.  Since the files in the ring buffer rotate based on *size* and not *time*, you can always run into this problem.

If you absolutely can't do port mirroring/copying/spanning/whatever you want to call it, you might be able to solve the problem using a combination of tcpslice and mergecap.

Tcpslice works like this:

tcpslice -w <output file> <start time> <end time> <input file(s)>...

So if you use tcpslice against the files in one ring buffer that contain the time slice you want, then against the other buffer, you'll have two output files that have the same start and end *times*.  Mergecap can take these two files and shuffle both streams together in the right order.

Caveats:

1)  Tcpslice - like editcap - must parse through all of the files completely to pull the packets you want.  It won't *split* a file into chunks of NN seconds.  Yet another possibility for the 'splitcap' utility that I'm considering.

2)  Tcpslice *must* have the input files listed in chronological order or it will skip files.  If you list the files BAC, for instance, it will pull all of the packets from B and C, but not A, because tcpslice will skip packets in its 'input stream' that it perceives to be out of order.  This is also why you have to use tcpslice *and* mergecap to get one output file when you're finished.

Anyway, hope that helps some, and keep in touch.  We're working on the same project!  :-)

--J

> -----Original Message-----
> From: Chris Rapier [mailto:rapier@xxxxxxx]
> Sent: Friday, November 08, 2002 4:14 PM
> To: ethereal-users@xxxxxxxxxxxx
> Subject: [Ethereal-users] Re-assembling half duplex streams
> 
> 
> I might be in a somewhat odd situation but maybe someone out 
> there has already 
> done this.
> 
> I built a GigE monitoring box that we use to keep track of 
> our commodity 
> connectivity. I did this using optical splitters and 
> diverting some of the light 
> to the recieve ports on one of two GigE cards in the monitor. 
> I'm able to 
> capture traffic reasonably well but I'm obviously limited in 
> that the dumps are 
> unidirectional. What I'd like to do is have a tool that will 
> merge the two half 
> duplex dumps into a full duplex one.
> 
> Can ethereal do anything like this? Would I need to sync the 
> GigE clocks to an 
> external source?
> 
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>