Re: Byte count instead of packet count?

[Rick Jones <rick.jones2 () hp com>]

Olof Backing wrote:
> Well,
> I've tried to search the 'net but came up failry empty handed with  any 
> decent solution for trying to use a byte counter instead of a  packet 
> dito. Since we all know that the packet length varies a lot, I  thought 
> that I wanted to have a byte size delimiter on my savefile.  In that way 
> I could say "give me 100GB of ethernet frames" and I  would get close to 
> that. Now I can only say "give me 100M of packets".
>
> On the other hand - should I even bother?

Perhaps not.  Typically when examining packet traces, only the first N 
bytes of the packet are particularly interesting - protocol and 
application headers - the rest isn't all that interesting.  Hence the 
snaplen option rather than saving an entire packet.

If the desire is to be certain you don't get too large a trace file, the 
combination of snaplen and packet count already bounds its size.

If you are interested in full packet contents then the packet count 
already bounds your trace file size.

And if you know or can guess at the average packet size, you can still 
get rather close to the 100GB of ethernet frames with the packet count 
and a full size snaplen.

Having said that, I suspect that the changes to add a byte count would 
be pretty straightforward if you wanted to implement them.  The only 
question outstanding I would think would be whether that should be a 
byte count based on snaplen captured, or the sum of the actual packet 
lengths.

rick jones
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.