tcpdump mailing list archives
Re: proposed new pcap format
From: Darren Reed <darrenr () reed wattle id au>
Date: Sat, 3 Apr 2004 01:52:26 +1000 (EST)
In some email I received from Christian Kreibich, sie wrote:
[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.]
What's the _real_ list address? The web page still has: tcpdump-workers () tcpdump org. Some of my emails seem to go missing rather to the list :-/ There's also tcpdump-workers () lists sandelman ca tcpdump-workers () lists tcpdump org Do I bombard all three?
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.
I'll repeat a comment I made elsewhere and that is currently, in an application I'm working on, we join captured data from multiple NICs with the same DLT type in the same file. Other parameters, such as the snaplen may differ, per capture instance. I should add that a nice C++ interface would be good too O:-) Darren - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Current thread:
- Re: proposed new pcap format Hannes Gredler (Apr 02)
- <Possible follow-ups>
- Re: proposed new pcap format Christian Kreibich (Apr 02)
- Re: proposed new pcap format Darren Reed (Apr 02)
- Re: proposed new pcap format Michael Richardson (Apr 02)
- Re: proposed new pcap format Michael Richardson (Apr 12)
- Re: proposed new pcap format Darren Reed (Apr 02)
- Re: proposed new pcap format Guy Harris (Apr 02)
- Re: proposed new pcap format Richard Sharpe (Apr 04)
- Re: proposed new pcap format Ryan Mooney (Apr 05)
- Re: proposed new pcap format Guy Harris (Apr 06)
- Re: proposed new pcap format Ryan Mooney (Apr 05)
- Re: Proposed new pcap format Michael Richardson (Apr 05)
- Re: Proposed new pcap format Loris Degioanni (Apr 06)
- Re: Proposed new pcap format Richard Sharpe (Apr 07)
- Re: Proposed new pcap format Michael Richardson (Apr 12)
- Re: Proposed new pcap format Loris Degioanni (Apr 06)
(Thread continues...)