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: [EMAIL PROTECTED] Some of my emails seem to go missing rather to the list :-/ There's also [EMAIL PROTECTED] [EMAIL PROTECTED] 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.
