tcpdump mailing list archives
Re: proposed new pcap format
From: Michael Richardson <mcr () sandelman ottawa on ca>
Date: Wed, 24 Mar 2004 10:03:53 -0500
-----BEGIN PGP SIGNED MESSAGE-----
"Jefferson" == Jefferson Ogata <Jefferson.Ogata () noaa gov> writes:
>> struct pcap1_info_container { >> bpf_u_int32 info_len; /* in bytes */ >> bpf_u_int32 info_type; /* enum pcap1_info_types */ Jefferson> That could be two int16s, couldn't it? You know what they say about premature optimization :-) type could be 16-bit. len, I'm hesistant. The high performance network people are presently complaining about the 64k limit on IP packets... >> unsigned char info_data[0]; >> }; >> struct pcap1_info_timestamp { >> struct pcap1_info_container pic; >> bpf_int32 thiszone; /* gmt to local correction */ Jefferson> I feel strongly that all pcap timestamps should be Jefferson> UTC. Think of it like UNIX file metadata; timestamps in Jefferson> inodes are UTC. Your local zone is an interpretion Jefferson> applied to those timestamps. okay. struct pcap1_info_timestamp { struct pcap1_info_container pic; bpf_u_int32 nanoseconds; /* 10^-9 of seconds */ bpf_u_int32 seconds; /* seconds since Unix epoch - GMT */ bpf_u_int16 macroseconds; /* 16 bits more of MSB of time */ bpf_u_int16 sigfigs; /* accuracy of timestamps - LSB bits */ }; Jefferson> If this is meant to handle the "wall time" notion Jefferson> proposed a few messages back, I think that is just Jefferson> metadata and should go in a metadata packet. Maybe there Jefferson> should be some standard metadata types. okay, meta data type for WALLTIME. Jefferson> indicating the system's time error offset. Then programs Jefferson> that read it can adjust timestamps on the fly. okay, meta data for skew. Can you write a structure for that? Jefferson> Significant figures in what base? I wouldn't go there. base 2, I'd think. Hmm. I see the problem. Can someone provide a clear notion? Do we have to go to units of 1/(2^32) of a second instead of 1/(10^9) then? - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr () xelerance com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQGGjV4qHRg3pndX9AQF51QQAyVV9iM71h548e3HXX+xXsleb2CIdU6xx 93hQCMaCoOQW6JAJ4fm7v0NYkkoxVV85+1jPydmmiglbrvQugqS24pPLzfhXvqhh gEoTkiQfn3QZnH89D5wjupFEWsl0jVlhbyK7gQmRM/Q1U5sFq80axTAZUNaREohp z5uHpu/BSgk= =qagj -----END PGP SIGNATURE----- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- proposed new pcap format Michael Richardson (Mar 23)
- Re: proposed new pcap format Guy Harris (Mar 23)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Hannes Gredler (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 23)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 25)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Guy Harris (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 24)
- Re: proposed new pcap format Michael Richardson (Mar 24)
- Re: proposed new pcap format Darren Reed (Mar 25)
- Re: proposed new pcap format Richard Sharpe (Mar 25)