On Mar 23, 2004, at 5:53 PM, 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.
OK - that's a bit much to write for every packet, though, as most of it is redundant.
Does each record have a pcap1_packet_header and *one* pcap1_info_container, or one or more up to block_len bytes? If the latter, you could have more than one packet per pcap1_packet header.
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?).
32-bit seconds, 32-bit nanoseconds.
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
...with that list presumably being expandable over time.
struct pcap1_info_container { bpf_u_int32 info_len; /* in bytes */ bpf_u_int32 info_type; /* enum pcap1_info_types */ unsigned char info_data[0]; };
struct pcap1_info_timestamp { struct pcap1_info_container pic; bpf_int32 thiszone; /* gmt to local correction */
We currently have that but don't use it - it's always zero. Should we start using it?
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
Similarly, that's never been set - should we start using it?
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
