ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] 2 gig limit on mergecap

From: "Hans Nilsson" <hasse_gg@xxxxxxxx>
Date: Wed, 22 Nov 2006 07:46:45 -1100
How complicated is it to merge two capture files? Do you have to change
much data in them or basically strip the headers of the second file and
then append it to the first?

On Wed, 22 Nov 2006 12:39:34 +0100, "Ulf Lamping" <ulf.lamping@xxxxxx>
said:
> Daniel Goolsby wrote:
> > I sifted through some of the archives but couldn't find anything 
> > whether this was going to be fixed.  I started capturing all port 80 
> > traffic.. every hour i send that tcpdump to another machine, so at the 
> > end of the day i wanted to merge all the traffic together in one nasty 
> > port 80 tcpdump file.
> >
> > regardless, mergecap stops at 2g.  I made sure and compiled merge on a 
> > Sparc Sun box, i also recompiled zlib to make sure it was at least 
> > compiled on a 64bit machine- no telling if it had any real effect.
> >
> > regardless, it still stops after the 2 gig limit has been reached on 
> > the new dump file i'm trying to create.  Are there any other tools 
> > that can merge tcpdump files that anyone knows of that doesn't have 
> > this limit?
> >
> > I could probably 'tcpreplay' the individual files on an interface that 
> > isn't being used, and tcpdump that one, but that's the only workaround 
> > i've thought up so far.
> >
> > Any suggestions/comments?
> Hi!
> 
> Can only give some background infos here.
> 
> I don't know if Sun Sparc 64 "long"s and/or "int"s are 64bits - if at 
> least the "long"s are 64 bit it could work.
> 
> zlib uses longs to keep file positions.
> 
> I've *very recently* changed Wireshark/wiretap to use gint64 instead of 
> longs (so 32bit platforms could work) - but couldn't test it if I found 
> all appearances ...
> 
> I didn't changed mergecap (and the other tools) so they might just use 
> ints to keep file position - which is probably not enough.
> 
> Regards, ULFL
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
-- 
  Hans Nilsson
  hasse_gg@xxxxxxxx

-- 
http://www.fastmail.fm - Does exactly what it says on the tin