Re: [tcpdump-workers] TPACKET_V3 support added big packet delivery delay and/or affected timestamps
On 4 December 2014 at 20:01, Guy Harris g...@alum.mit.edu wrote:
If your program needs to have packets delivered as soon as they arrive, it
should, if the version of libpcap with which it's being built has the
pcap_set_immediate_mode() API
Thanks. I switched to the pcap_create() API from pcap_open_live() (my
code predates pcap_create()) and set immediate mode, and that did it.
https://github.com/ThomasHabets/arping/commits/arping-2.x
Thanks for your help.
--
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] TPACKET_V3 support added big packet delivery delay and/or affected timestamps
Affected releases: 1.5.0 and up.
Steps to reproduce:
git checkout -f libpcap-1.5.0
./configure --prefix=/opt/badpcap make make install
git clone github.com/ThomasHabets/arping
cd arping
./boostrap.sh
./configure make
LD_PRELOAD=/opt/badpcap/lib/libpcap.so ./src/arping your.local.next.hop
Actual behaviour:
$ sudo sh -c LD_PRELOAD=$HOME/opt/buggypcap/lib/libpcap.so ./arping 10.0.0.1
ARPING 10.0.0.1
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=0 time=52.633 msec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=1 time=90.928 msec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=2 time=115.183 msec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=3 time=285.153 msec
^C
--- 10.0.0.1 statistics ---
4 packets transmitted, 4 packets received, 0% unanswered
Expected (and received with 1.4.0):
$ sudo sh -c LD_PRELOAD=$HOME/opt/goodpcap/lib/libpcap.so ./arping 10.0.0.1
ARPING 10.0.0.1
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=0 time=817.060 usec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=1 time=895.977 usec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=2 time=759.840 usec
60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=3 time=827.074 usec
^C
--- 10.0.0.1 statistics ---
4 packets transmitted, 4 packets received, 0% unanswered
Notice the unit difference. About a hundred milliseconds vs about 800
microseconds.
What appears to be the relevant commit:
https://github.com/the-tcpdump-group/libpcap/commit/8ada1d5b98ac62c4ae9acbecb0639beeebd8a359
Questions:
Is TPACKET V3 (and V2?) much slower than V1? Can I disable them?
Is this actual delay, or just a different way of measuring?
--
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Monotonic clock timestamp on packets
Hi.
Has anyone looked into timestamping the captured packets using
clock_gettime(CLOCK_MONOTONIC, ...)?
I'm thinking adding a struct timespec to struct pcap_pkthdr and filling
that in addition to the struct timeval.
For a request-reply situation a monotonic clock is much more reliable than
gettimeofday().
-
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Monotonic clock timestamp on packets
On Tue, 4 May 2010, Guy Harris wrote:
BTW, note that if you call clock_gettime(), there is *NO* guarantee
that the time it returns has anything to do with the time the packe
arrived; it tells you the time when it's called, not the time when the
packet arrived.
Exactly. That's why I asked if anyone has taken a look at it. Because
calling it from the application at pcap_dispatch time would be useless.
Just like calling it from libpcap an arbitrary time too late would be
useless.
So if the underlying systems don't provide a monotonic clock for packet
arrival time then that's that.
take a look at the code.
Huh? I never said this.
-
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Monotonic clock timestamp on packets
On Tue, 4 May 2010, Prasanna Kumar Nelam wrote:
If u want to that time the pkthdr u have the timestructure have the time in
seconds and microseconds.
In wall clock time, yes. The problem is that this breaks when the time is
changed, using NTP or by some other means. You can even end up with a
negative time delta.
-
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
