On Dec 28, 2012, at 3:14 PM, Maik Jäkel <em...@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
