Thanks for your replies Michal and Guy,
The main handicap is using libpcap based user space tools like tcpdump, tcpstat, tshark on my project. If I change Libpcap usages on that user level applications, I must leave the upstreams of that applications so I can not face leaving this much project's upstreams. For this reason I desired to adapt Libpcap which is dynamically linked in other user space tools that are mentioned in the previous sentence. I have defined an pcap_t->fd array and coded the multiple socket adaptation on Libpcap 1.7.3. It seems running successfully. I want to tanks you again for your helps. Best regards. Tugrul On Thu, Jun 4, 2015 at 7:38 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Jun 4, 2015, at 12:37 AM, Michal Sekletar <msekl...@redhat.com> wrote: > > > Can't you just pcap_open more interfaces and for each pcap_t* you get > call pcap_fileno which will return back file descriptor for that capture. > Then you can use select/epoll to multiplex on those descriptors. > > Or, in newer versions of libpcap, call pcap_get_selectable_fd(), which, > for devices on which you can capture but on which you *can't* use > select()/poll()/epoll()/kqueues, returns -1. (Yes, they do exist; the DAG > card drivers don't support it.) > > BTW, that's also one problem with having a single pcap_t refer to multiple > devices - a lot of code out there expects a single descriptor on which it > can do select()/poll()/epoll()/kqueues, and you can't do that if a single > pcap_t refers to multiple devices. > _______________________________________________ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
