Re: proposed new pcap format

[Christian Kreibich <christian () whoop org>]

[I've tried to get this to the list about four times now and it always
came back with a different reason -- I hope this one will make it to
the new list. Thanks.]

On Wed, 2004-03-24 at 03:31, Jefferson Ogata wrote:
> Michael Richardson wrote:
> > This is what I would propose as revision.
> > Note that the pcap1_packet_header is present on every packet. One can
> > merge pcap files together with "cat" if one likes.
>
> That's a nice feature, and one we should try to maintain if possible.

There's another thing I'd like to point out: the new scheme, in its
current state, doesn't provide the snaplen value that the old
pcap_file_header provides. I think a *lot* of applications use that
value to allocate a buffer to store packet data before starting to read
packets.

I think I'd like to see a somewhat stricter layout than Michael's scheme
suggests right now, i.e., put file-wide metadata at the beginning of the
file, in a fashion equally extensible as the current per-packet
structure, and after that, allow only a kind of pcap1_packet_header that
(among possibly others) contains precisely one pcap1_info_packet.

I agree that the ability to cat together trace files would be nice.
However if that's the only benefit, while otherwise every
packet-iterating application becomes a whole lot more complicated
because it must find a way to deal with pure metadata without any packet
data at random points in the file (how to display? discard what you
don't understand? keep it? ...) then I'm not sure if it's worth it.

Just imho.

Best regards,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org


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