[Ntop] PF_RING tcpdump, incorrect timestamps

[Jon Schipp]

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.com> 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.com
>
>