Thanks for your quick response. Sorry if I did not explain the problem
clearly enough for you. Let me try again...
In the PCAP file, each packet has a timestamp which, if viewed with a tool
like ethereal, would be displayed as hh:mm:ss.yyyyyy. In order to get at
this timestamp information when using Net::Pcap, I would have to do the
following:
$tv_sec = $hdr->{tv_sec}; # seconds since the beginning of the epoch
$tv_usec = $hdr->{tv_usec}; # fractional part of timestamp
And yes, I agree that tv_usec is an integer (which is why I use %06d in my
sprintf format string and not %06f). However, I think the confusion came
from the fact that it represents the fractional part of the timestamp value
(i.e. the part after the decimal point).
The problem that I found is that if the yyyyyy part contains a zero at the
beginning (e.g. hh:mm:ss.012345 as shown by a tool like ethereal), when I
use $tv_usec to create a floating point number, i.e.
$fp_tv = "$tv_sec.$tv_usec";
I get <epoch seconds>.12345 and not <epoch seconds>.012345, i.e. the
leading 0 is missing from the fractional part of the number.
In order to rectify this problem, I used:
$tv_usec = sprintf "%06d", $hdr->{tv_usec};
so that it is padded with the necessary zeros at the beginning.
Hope that helps.
Regards,
Nick
This transmission may contain information that is privileged, confidential
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is STRICTLY PROHIBITED. If you received this
transmission in error, please immediately contact the sender and destroy
the material in its entirety, whether in electronic or hard copy format.
"Sébastien
Aperghis-Tramoni
via RT" To
<bug-Net-Pcap@rt. Nick Smith/CanWest/IBM@IBMCA
cpan.org> cc
05/04/2007 01:44 Subject
PM Re: [rt.cpan.org #26937] Bug report
for Net-Pcap
Please respond to
bug-Net-Pcap@rt.c
pan.org
<URL:
http://rt.cpan.org/Ticket/Display.html?id=26937 >
Hello,
Show quoted text> I have discovered that the tv_usec value that is returned strips off
> leading zeros. For example, if a packet's timestamp value is
> 0.012345, the
> tv_usec value will be returned as 12345, thus making it incorrect
> by an
> order of magnitude.
Sorry but I do not understand the problem: tv_usec is a long integer,
so it clearly cannot get floating point values.
Can you show an example of code which exposes your problem?
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.