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.
A suggestion was made to accomodate the nano-second resolution from AIX. Can you tell me what they do for that? just more bits, sure, but is there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
enum pcap1_info_types { PCAP_DATACAPTURE, PCAP_TIMESTAMP, };
struct pcap1_info_container { bpf_u_int32 info_len; /* in bytes */ bpf_u_int32 info_type; /* enum pcap1_info_types */
That could be two int16s, couldn't it?
unsigned char info_data[0]; };
struct pcap1_info_timestamp { struct pcap1_info_container pic; bpf_int32 thiszone; /* gmt to local correction */
I feel strongly that all pcap timestamps should be UTC. Think of it like UNIX file metadata; timestamps in inodes are UTC. Your local zone is an interpretion applied to those timestamps.
If this is meant to handle the "wall time" notion proposed a few messages back, I think that is just metadata and should go in a metadata packet. Maybe there should be some standard metadata types.
In addition, represented as metadata, I think zone information should be an Olsen zone name. There should be another metadata type for time error offset. Thus if you have a capture from a system with an unsynchronized clock, you could retrospectively insert a metadata packet at the beginning indicating the system's time error offset. Then programs that read it can adjust timestamps on the fly.
Also, it would redundant to put zone info in each timestamp.
> struct timeval ts; /* time stamp */ > bpf_u_int32 sigfigs; /* accuracy of timestamps */ > };
Significant figures in what base? I wouldn't go there.
-- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
