-[ 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.
