Re: Fwd: Re: Printing nanosecond timestamp information in raw output

[Guy Harris <guy () alum mit edu>]

On Dec 28, 2012, at 3:14 PM, Maik Jäkel <email () maikjaekel de> wrote:

> My target environment is android with a 2.6.35.14-kernel.
> I realize that the timestamp is taken "a long time" after the reception of the packet. I didn't know a better way, 
> though and hoped that the execution time between the reception of the packet and taking the timestamp is relatively 
> constant (with an uncertainty of 4ns or so).

If you want a timestamp, you need a real-time clock, not an execution-time clock, so what matters isn't the *execution* 
time, what matters is the *real* time, which is not guaranteed to be relatively constant.  If your process isn't 
competing with any other processes (including daemons as well as other applications) for any of the processor cores, or 
if the process is running with some form of real-time scheduling enabled so that the CPU will never be taken away from 
it by the scheduler, *maybe* the execution time and real time will be close to the same, but even that's not guaranteed 
unless all of the virtual memory the packet capture and printing code path is wired into main memory (so you don't take 
any page faults).

As this is Linux-specific, the easiest way to get nanosecond-resolution time stamps is *NOT* to simply modify tcpdump.  
I would suggest, instead, that you:

        modify *libpcap*, so that it returns nanosecond-resolution time stamps;

        modify tcpdump, so that it assumes that the tv_usec in the time stamps it gets from libpcap is in units of 
nanoseconds rather than microseconds;

        statically link your modified tcpdump with your modified libpcap and use that.

To modify libpcap, change

#ifdef HAVE_TPACKET2
                case TPACKET_V2:
                        tp_len     = h.h2->tp_len;
                        tp_mac     = h.h2->tp_mac;
                        tp_snaplen = h.h2->tp_snaplen;
                        tp_sec     = h.h2->tp_sec;
                        tp_usec    = h.h2->tp_nsec / 1000;
                        break;
#endif

in pcap-linux.c to

#ifdef HAVE_TPACKET2
                case TPACKET_V2:
                        tp_len     = h.h2->tp_len;
                        tp_mac     = h.h2->tp_mac;
                        tp_snaplen = h.h2->tp_snaplen;
                        tp_sec     = h.h2->tp_sec;
                        tp_usec    = h.h2->tp_nsec;
                        break;
#endif

A 2.6.35 kernel should support version 2 of the "turbopacket" memory-mapped Linux packet capture mechanism, i.e. 
TPACKET_V2, so it should be able to supply nanosecond-resolution time stamps, and that should be the mechanism used, by 
default, by libpcap.

> Does the above mentioned kernel have the feature you mentioned?

It supports version 2 of the "turbopacket" memory-mapped Linux packet capture mechanism, which supplies 
nanosecond-resolution time stamps from the kernel, so it has that feature.

It also supports hardware time stamps *IF* the network adapter and driver support it.  I suspect the network adapters 
on Android devices don't, however, so you'll probably have to live with software timestamps.  If you're modifying the 
latest libpcap and tcpdump, those will have support for hardware timestamps, so you might try running tcpdump with the 
command-line option "-j adapter" - if that works, you get hardware time stamps, but, if it doesn't (i.e., if it 
complains that the timestamp type isn't supported), try not using "-j adapter".  You *might* be able to get better, but 
still software-based, timestamps with "-j host_hiprec", but those time stamps might be more expensive to fetch and 
aren't synchronized with the host clock.

> What do I have to do print that timestamp together before the raw packet?

Modify tcpdump so that it assumes that timestamps are in the form of seconds and nanoseconds, and then just let it 
print the regular timestamp.  Do *not* attempt to get, or print, timestamps yourself.

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers