[tcpdump-workers] Multiple interface listening modification

Tugrul Erdogan h.tugrul.erdogan at gmail.com
Wed Jul 1 01:27:34 EDT 2015

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.

On Thu, Jun 4, 2015 at 7:38 PM, Guy Harris <guy at alum.mit.edu> wrote:

> On Jun 4, 2015, at 12:37 AM, Michal Sekletar <msekleta at 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 at lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

More information about the tcpdump-workers mailing list