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)
