Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Filtering a very large capture file

From: "Small, James" <JSmall@xxxxxxxxxxxx>
Date: Fri, 26 Jan 2007 12:02:20 -0500
I wonder if ngrep would work for you:
http://ngrep.sourceforge.net/

There are binaries for most platforms including Linux and Windows.

Perhaps you could do something like this:
ngrep -I input.cap -O output.cap "regex"

I tried and it seems to work, although I only used a 20MB capture file.

--Jim

> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-
> bounces@xxxxxxxxxxxxx] On Behalf Of Seymour Dupa
> 
> What about 'grep'?
> I used it a lot in my DOS days.  I'm sure there is/are
> Windows versions.  It's quite powerful with many
> wildcard characters and search patterns.  It will do a
> lot of filtering for you.
> You mauy have to run it several times for the
> different search parameters.
> 
> John
> 
> --- Guy Harris <guy@xxxxxxxxxxxx> wrote:
> 
> >
> > On Jan 25, 2007, at 8:23 PM, Stuart MacDonald wrote:
> >
> > > I've read the man pages on the tools that come
> > with Wireshark. I was
> > > hoping to find a tool that opens a capture,
> > applies a filter and
> > > outputs matching packets to a new file. Here's a
> > sample run of the
> > > hypothetical filtercap tool:
> > > # filtercap -r very-large.eth -w
> > only-infrequent.eth -f
> > > "tcp.port==50000"
> >
> > 	tcpdump -r very-large.eth -w only-infrequent.eth
> > tcp port 50000
> >
> > That can't do arbitrary display filtering, but truly
> > *arbitrary*
> > display filtering has problems with reassembly
> > (i.e., a filter that
> > matches something in the reassembled portion of the
> > packet can't match
> > anything but the last packet).  It also can't handle
> > non-libpcap
> > capture files, but given that your capture file is
> > *from* tcpdump,
> > it's obviously readable by tcpdump....
> >
> >
> > > tshark is almost the right thing, except that
> > tshark also tries to
> > > read in the whole capture first instead of
> > processing it like editcap.
> >
> > No, actually, it *does* process it like editcap;
> > neither it nor
> > Wireshark read the entire capture file into memory.
> > They *do* keep
> > reassembled data in memory, but that's another
> > matter.