I ran it on a 64 bit version of Red Hat Enterprise 4. I was doing a live
capture on a busy tap to get an idea about the protocols being used and
byte counts. I did not roll past 2^32 frames. Looks like 100 million was
the most I saw. Since I was updating the byte counter I just updated the
frame counter as well just in case.
So doing a live capture long enough I could probably roll the frame
counter as well.
I use the stats part often to help characterize the traffic and volume.
Thanks,
Todd
On Mon, 2007-04-16 at 13:15 +0800, Jeff Morriss wrote:
>
> Todd Vollmer wrote:
> > Sorry for the repost. The wiki doesn't mention putting PATCH in the
> > subject line and I am new here.
> >
> > I have attached a patch for the protocol hierarchy statistics (-z io,
> > phs). It's a simple update from a 32 bit unsigned integer to a 64 bit
> > version. I am a little uncertain about the portability of the new
> > include but I tied to follow how it was done else where in the code.
>
> It should be portable enough since Wireshark now requires 64-bit types.
> And I'm all about 64-bit counters (32-bits is so, like, 1990's), but:
>
> - Did you actually have a capture with more than 2^32 frames? On what
> OS and with how much RAM? I didn't think Wireshark could read files
> that big and I certainly thought it would run out of memory before it
> got that far. Just curious, really...
>
> - If Wireshark/tshark are going to support more than 2^32 frames,
> there's more changes that should happen too: the frame numbers are
> currently guint32, for example. Rollover there will mess up the
> statistics the taps are gathering.
