[Winpcap-users] Re: header->ts.tv_usec

[Marcel van Lieshout]

wow, that's quite an explanation and just what I needed. Thanks!

Marcel

Guy Harris wrote:
> On Jun 8, 2006, at 4:52 AM, Vasily Borovyak wrote:
> 
>> I do not understand why do you need that. Could you please explain?
>> As far as I know timeval is used not for the time representing but
>> for the short period of time representing.
> 
> No.  "struct timeval" is used, in UN*X systems, used both for
> absolute times (seconds since January 1, 1970, 00:00:00 GMT, and
> microseconds since that second) and relative times (seconds and
> microseconds since some other point in time).
> 
> WinPcap is a port of libpcap to Windows, and libpcap, having
> originated on UN*X systems, uses the "struct timeval" in a pcap file
> as an absolute time.
> 
> The answer to "what is the easiest way to generate the timestamp from
> the current time?" depends on how you get the current time.
> 
>> So I can only assume the answer for your question.
>> I made a quick look at the wpcap sources and found these lines:
>>       timeout.tv_sec = to_ms / 1000;
>>       timeout.tv_usec = (to_ms * 1000) % 1000000;
>> Where to_ms is the some microseconds value.
> 
> Note that "the wpcap sources" are a combination of the *full* libpcap
> source - including support for many UN*Xes as well as Win32 - and
> source for the WinPcap extensions to libpcap, the packet.dll library
> atop which WinPcap runs, and the drivers that packet.dll uses.
> 
> The places that do
> 
> timeout.tv_sec = to_ms / 1000;
> timeout.tv_usec = (to_ms * 1000) % 1000000;
> 
> are the pcap-*.c files for various UN*Xes for the DAG API library for
> Endace capture cards on UN*X; the timeout value in pcap_open_live()
> is an integral number of milliseconds, but the calls to set the
> timeout in the underlying packet capture mechanism tend to take a
> "struct timeval" as an argument.  In that case, the "struct timeval"
> represents a relative time (time since the current read on the packet
> capture device was started, or time since the first packet arrived
> after that read started, depending on the OS), not an absolute time,
> so that's not directly relevant to what Marcel wants.
> 
> If you have the current time as a FileTime, i.e. a 64-bit value
> representing the number of 100-nanosecond intervals since January 1,
> 1601, 00:00:00 "GMT" (Microsoft says "UTC", but not only didn't UTC
> exist in 1601, even GMT didn't), you'd convert that to a "struct
> timeval" by:
> 
> dividing it by 10000000 and saving both the quotient and the
> remainder, giving:
> 
> the number of 100-nanosecond intervals since the previous "on a 1-
> second boundary" instant (the remainder);
> 
> the number of seconds between January 1, 1601, 00:00:00 "GMT" and
> that instant (the quotient);
> 
> subtracting from the quotient the number of seconds between January
> 1, 1601, 00:00:00 "GMT" and January 1, 1970, 00:00:00 GMT (that's
> 11644473600), to give the number of seconds since January 1, 1970,
> 00:00:00 GMT, and using that for "tv_sec";
> 
> dividing the remainder by 10 (or, to round it up, adding 5 and
> dividing by 10), to give the microseconds since the aforementioned
> instant, and using that for "tv_usec".
> 
> Converting other time formats are left as an exercise for the reader.
> 
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users