tcpdump mailing list archives

Re: Multiple interface capture and thread safety


From: rixed () happyleptic org
Date: Thu, 10 May 2012 16:59:51 +0200

-[ Thu, May 10, 2012 at 04:43:50PM +0200, Wiener Schnitzel ]----
I need to perform packet sniffing on several interfaces at the same
time.
My natural approach would be to open a pcap_t object for each
interface and place a "select" - considering Linux -call to deal
with packet dispatching. My only constraint is that I have to treat
the received packets in chronological order: indeed, I would like to
process the data as it gets to the interfaces, without introducing
any reordering. If I am not mistaken, it might be possible that a
"select" call does not read data in temporal order, if multiple FDs
are ready at the time the process is scheduled for running by the
OS. Is that correct ?

Yes, but anyway as libpcap (and the kernel) will batch the packets
sent to each pcap_t handle you will have some reordering taking place
independantly of select().

A work-around to this problem might be to move the capture on
different threads: each thread has its own pthread_t object and
captures traffic on a different interface. In this case, I do not
have a clear picture about which parts of libpcap are thread-safe
and which not (my version of reference is the 1.1.1); I have found
really old posts about thread-safety issues in pcap_compile and
pcap_setfilter (which I would need: 1 common filter for each thread)
but nothing more.

libpcap is mostly thread safe (I say mostly because I don't know for
your version but I never encountered any issue with modern versions -
and by modern I mean the version shipped with Debian stable).

If you go with threads, you will still need to ensure that packets are
processed in order, though. But do you really need to process packets
received on distinct interfaces in timestamp order? What's the purpose?

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Current thread: