[tcpdump-workers] Multiple interface capture and thread safety status in libpcap
Hi all, 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 ? 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. To sum up: 1) Could I/O multiplexing reorder packets during multiple interfaces sniffing ? 2) Which are the caveats to take into account when capturing from different interfaces using threads (1 thread per interface, same BPF filter for each thread) ? Which parts of libpcap are not thread-safe (v. >= 1.1.1) ? Thank you Alberto Balesena - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Multiple interface capture and thread safety
-[ 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.
Re: [tcpdump-workers] Multiple interface capture and thread safety
On 10.05.2012 16:59, ri...@happyleptic.org wrote: -[ 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(). Good to know. 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? Are you talking about either reordering in libpcap or the merging of the packets ? As I have to deal with asymm. paths and perform flow analysis, I must ensure that the packets of a flow are analyzed in temporal order, no matter from which interface they came through. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Multiple interface capture and thread safety
> As I have to deal with asymm. paths and perform flow analysis, I must > ensure that the packets of a flow are analyzed in temporal order, no > matter from which interface they came through. You'll probably only manage that if the underlying low level device driver (or preferably the hardware itself - because of interrupt mitigation) adds a rx timestamp to the frame AND that value is made available through the pcap library. That might mean a very recent linux kernel (there are current discussions on netdev about timestamps). David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
