Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NTop: Users

PF_RING tcpdump, incorrect timestamps

 

 

NTop users RSS feed   Index | Next | Previous | View Threaded


jonschipp at gmail

Mar 12, 2012, 7:24 AM

Post #1 of 5 (986 views)
Permalink
PF_RING tcpdump, incorrect timestamps

Hello all,

I'm having an issue with the PF_RING tcpdump program reporting an
incorrect timestamp.
My kernel's timestamp reports my correct time via 'date' (1) but the
tcpdump program included with PF_RING shows a time much different.
e.g. at 10 a.m. (correct time), the pf_ring tcpdump reports at
timestamp of 2:00 p.m. (14:00).

If I run the original tcpdump program, as compiled from the sources on
tcpdump.org, it reports the correct time.
If I run a version of ngrep with PF_RING support it reports the
correct timestamp. The problem seems to be with tcpdump.

System is Linux: Ubuntu Server 11.04, kernel 2.6.38-13, Intel cards
that use the e1000 driver.
PF_RING 5.2.2, transparent_mode=0

Anyone else experienced this? Any idea on how to fix this?

Thanks
Jon
_______________________________________________
Ntop mailing list
Ntop [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop


alex.dupuy at mac

Mar 13, 2012, 5:53 PM

Post #2 of 5 (965 views)
Permalink
PF_RING tcpdump, incorrect timestamps [In reply to]

Hi Jon,

The timestamp in your e-mail:
> Date: Mon, 12 Mar 2012 10:24:54 -0400

indicates that you (and me) are in EST (UTC - 4:00), which is exactly the amount of the incorrect offset to the time you are seeing:
> My kernel's timestamp reports my correct time via 'date' (1) but the
> tcpdump program included with PF_RING shows a time much different.
> e.g. at 10 a.m. (correct time), the pf_ring tcpdump reports at
> timestamp of 2:00 p.m. (14:00).


In other words, the PF_RING tcpdump is displaying timestamps in GMT (UTC).

Where did the tcpdump binary you are using come from? Was it provided in binary form with the PF_RING software? Did you compile it from the PF_RING distribution? What is the value of the TZ environment variable? If you set that variable explicitly (export TZ=America/New_York) do you get different output? If you use the -w option to write binary tcpdump data to a file (this should always be in UTC) and then print it using tcpdump -r, what timestamps do you see? Are they different depending on the tcpdump binary you use to print them?

If you can answer those questions, the solution to your problem may become apparent to you.

@alex
--
mailto:alex.dupuy [at] mac



_______________________________________________
Ntop mailing list
Ntop [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop


alex.dupuy at mac

Mar 14, 2012, 6:31 PM

Post #3 of 5 (939 views)
Permalink
Re: PF_RING tcpdump, incorrect timestamps [In reply to]

On Mar 14, 2012, at 10:04, Jon Schipp wrote:

> Thanks for the reply Alex.
>
> The TZ variable on my system has not been set.
>
> It makes sense that it is displaying the UTC time, I overlooked that
> idea. I changed the TZ variable to a few different timezones and the
> original tcpdump program compiled from source from tcpdump.org changes
> appropriately as each new value of TZ is set. However, the PF_RING
> version of tcpdump does not seem to respect the TZ variable. I
> downloaded the source and compiled the source in the userland
> directory from the latest PF_RING tarball. As to why that is I'm not
> sure.
>
> If I write to disk (-w) and read with analysis tools other than the
> pf_ring modified tcpdump, the tools report the EST format of the time,
> which is the way I like it...easier to read.
>
> I set the TZ variable to "EST+4" and then recompiled tcpdump source
> from the PF_RING release, just to see if anything changed.
> It's still the same. When you mentioned TZ I thought "Voila" but the
> modified tcpdump does not seem to pay attention to TZ like the
> original does.
>
> Am I missing something? Any other pointers?


Without looking at the PF_RING modified tcpdump sources in some detail, I can't say, but perhaps there was a localtime() call changed to gmtime() somewhere.

@alex
--
mailto:alex.dupuy [at] mac



_______________________________________________
Ntop mailing list
Ntop [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop


alex.dupuy at mac

Mar 15, 2012, 1:07 AM

Post #4 of 5 (943 views)
Permalink
Re: PF_RING tcpdump, incorrect timestamps [In reply to]

Earlier, I wrote:
> Without looking at the PF_RING modified tcpdump sources in some detail, I can't say, but perhaps there was a localtime() call changed to gmtime() somewhere.

Diffing the PF_RING and stock tcpdump.c files reveals the reason the modified tcpdump is printing timestamps in UTC. On lines 1598-1610, the following code replaces the stock tcpdump.c call to ts_print:
> #if defined(HAVE_PF_RING)
> {
> struct ns_pcaphdr *myhdr = (struct ns_pcaphdr*)h;
> int s = myhdr->ts.tv_sec % 86400;
> u_int nsec = myhdr->ns % 1000;
>
> printf("%02d:%02d:%02d.%06u%03u ",
> s / 3600, (s % 3600) / 60, s % 60,
> (unsigned)h->ts.tv_usec, nsec);
> }
> #else
> ts_print(&h->ts);
> #endif


The replacement code (only active ifdef HAVE_PF_RING) prints three more digits of precision (nanoseconds rather than just microseconds) in the timestamp. This will print quasi-random garbage numbers in the last three digits if the tcpdump input source is not a live PF_RING capture; furthermore, any -t options to select a different timestamp style will be ignored, as well as the local timezone offset, as you noticed.

If you don't need the extra (and probably fictitious, on most systems without interface-based timestamp support, recently added to libpcap/tcpdump with -j option - not present in PF_RING version) nanosecond precision, you can just change the #if on line 1598 to "#if 0" to get normal timestamp printing support in tcpdump.

@alex
--
mailto:alex.dupuy [at] mac


jonschipp at gmail

Mar 15, 2012, 7:32 AM

Post #5 of 5 (963 views)
Permalink
Re: PF_RING tcpdump, incorrect timestamps [In reply to]

Alex,

That did the trick. Thanks a lot, I appreciate it.

Jon

On Thu, Mar 15, 2012 at 4:07 AM, Alexander Dupuy <alex.dupuy [at] mac> wrote:
> Earlier, I wrote:
>
> Without looking at the PF_RING modified tcpdump sources in some detail, I
> can't say, but perhaps there was a localtime() call changed to gmtime()
> somewhere.
>
>
> Diffing the PF_RING and stock tcpdump.c files reveals the reason the
> modified tcpdump is printing timestamps in UTC.  On lines 1598-1610, the
> following code replaces the stock tcpdump.c call to ts_print:
>
> #if defined(HAVE_PF_RING)
> {
>  struct ns_pcaphdr *myhdr = (struct ns_pcaphdr*)h;
>  int s = myhdr->ts.tv_sec % 86400;
>  u_int nsec = myhdr->ns % 1000;
>
>  printf("%02d:%02d:%02d.%06u%03u ",
> s / 3600, (s % 3600) / 60, s % 60,
> (unsigned)h->ts.tv_usec, nsec);
> }
> #else
> ts_print(&h->ts);
> #endif
>
>
> The replacement code (only active ifdef HAVE_PF_RING) prints three more
> digits of precision (nanoseconds rather than just microseconds) in the
> timestamp.  This will print quasi-random garbage numbers in the last three
> digits if the tcpdump input source is not a live PF_RING capture;
> furthermore, any -t options to select a different timestamp style will be
> ignored, as well as the local timezone offset, as you noticed.
>
> If you don't need the extra (and probably fictitious, on most systems
> without interface-based timestamp support, recently added to libpcap/tcpdump
> with -j option - not present in PF_RING version) nanosecond precision, you
> can just change the #if on line 1598 to "#if 0" to get normal timestamp
> printing support in tcpdump.
>
> @alex
> --
> mailto:alex.dupuy [at] mac
>
>
_______________________________________________
Ntop mailing list
Ntop [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop

NTop users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.