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:[email protected]
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
