Skip Menu |

This queue is for tickets about the Net-Pcap CPAN distribution.

Report information
The Basics
Id: 26937
Status: resolved
Priority: 0/
Queue: Net-Pcap

People
Owner: Nobody in particular
Requestors: nsmith [...] ca.ibm.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Bug report for Net-Pcap
Date: Fri, 4 May 2007 12:38:56 -0700
To: bug-Net-Pcap [...] rt.cpan.org
From: Nick Smith <nsmith [...] ca.ibm.com>
Hi, 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. A workaround is to pad the answer as follows: $tv_usec = sprintf "%06d", $hdr->{tv_usec}; Distribution name: Net-Pcap version 0.14 Perl version: This is perl, v5.8.0 built for i386-linux-thread-multi Operating system: Linux localhost.localdomain 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux Thanks for a very useful module. 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.
Subject: Re: [rt.cpan.org #26937] Bug report for Net-Pcap
Date: Fri, 04 May 2007 22:35:14 +0200
To: bug-Net-Pcap [...] rt.cpan.org
From: Sébastien Aperghis-Tramoni <saper [...] cpan.org>
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.
Subject: Re: [rt.cpan.org #26937] Bug report for Net-Pcap
Date: Fri, 4 May 2007 15:21:20 -0700
To: bug-Net-Pcap [...] rt.cpan.org
From: Nick Smith <nsmith [...] ca.ibm.com>
Download graycol.gif
image/gif 105b
graycol.gif
Download pic25806.gif
image/gif 1.2k
pic25806.gif
Download ecblank.gif
image/gif 45b
ecblank.gif
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.
Subject: Re: [rt.cpan.org #26937] Bug report for Net-Pcap
Date: Sat, 5 May 2007 02:18:01 +0200
To: bug-Net-Pcap [...] rt.cpan.org
From: Sébastien Aperghis-Tramoni <saper [...] cpan.org>
Show quoted text
> 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.
Call me dense but I still don't understand where is the problem: this is a formatting issue, not a bug in Net::Pcap. A Perl number is stored using a machine native integer or float, not as a string, so I can't prefix it with zeroes. Plus you already know how to use sprintf () so I just don't understand what you're expecting from me. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Subject: Re: [rt.cpan.org #26937] Bug report for Net-Pcap
Date: Sat, 5 May 2007 08:27:19 -0700
To: bug-Net-Pcap [...] rt.cpan.org
From: Nick Smith <nsmith [...] ca.ibm.com>
Actually, you can call me dense. Although I read the documentation for Net::Pcap, I obviously did not understand what it was telling me with respect to the tv_usec header field. You are right, this is a formatting issue and the bug is in my head not in Net::Pcap. However, I am not the only one who has fallen into the trap of thinking that I can do something as silly as $timestamp = "$hdr->{tv_sec}.$hdr->{tv_usec}"; I guess that I have fallen into the trap of thinking that everything should be handed to me on a plate because Perl makes it so easy when it comes to handling numbers (I can take a string and use it like a number). Perhaps when / if the Net::Pcap module is updated in the future you could add a brief note to the documentation to make it clear that tv_usec is not a string representation of the fractional part of the timestamp. Thanks for your time and sorry to bother you with this. 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.
Subject: Re: [rt.cpan.org #26937] Bug report for Net-Pcap
Date: Sat, 5 May 2007 18:14:54 +0200
To: bug-Net-Pcap [...] rt.cpan.org
From: Sébastien Aperghis-Tramoni <saper [...] cpan.org>
Show quoted text
> Perhaps when / if the Net::Pcap module is updated in the future you > could > add a brief note to the documentation to make it clear that tv_usec > is not > a string representation of the fractional part of the timestamp.
There's a pending version 0.15. This formatting issue seems quite obvious for me but maybe I'll add a note about it. Show quoted text
> Thanks for your time and sorry to bother you with this.
No problem. Thanks for using Net::Pcap. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.