Bug#793098: ITP: pfring -- PF_RING is a high-speed packet capture, filtering and analysis framework.
Hi Hilko,
On 07/22/2015 06:03 PM, Hilko Bengen wrote:
* Ander Juaristi:
PF_RING is a high-speed packet capture, filtering and analysis
framework. It's composed of a kernel module that does all the
low-level packet capture work, and a user-space library
(libpfring.so/libpfring.a) applications written in C can be linked
against.
Nice to see that somebody wants to work on this.
Also, it provides some specialized PF_RING-aware drivers for the most
popular NICs that provide better performance, but whose installation
is optional. The kernel module and the drivers are distributed under
the GNU GPLv2 license, and the user-space library under LGPLv2.1.
This is only half the truth -- there are closed bits that are needed to
enable the "DNA" feature.
Now that you mention, I wasn't really sure whether I wanted to include the PF_RING-aware drivers at the time I wrote the ITP, and I'm still not sure. What's more, I think there are license issues involved. At least with PF_RING ZC, not sure with DNA... Will research further.
Thanks for pointing this out.
The source tarball also contains patched versions of not quite up-to-date
versions of some software:
- tcpdump
- libpcap
- snort
Do you have plans to get any of those changes integrated into existing
packages?
It's possible to compile PF_RING stripping out all the libpcap code. That is, a pure, clean PF_RING. My intention was to create two groups of packages, the first one featuring the 'clean' PF_RING (for example: libpfring, libpfring-dev, libpfring-doc, pfring, ...) and the second one featuring PF_RING with the pieces of code taken from libpcap (I would call them libpfring-bpf, libpfring-bpf-dev, libpfring-bpf-doc, pfring-bpf, ...).
Why would I do that? Essentially because (leaving performance differences apart), the libpfring.so version compiled with libpcap exports some extra functions that are used to parse and apply BPF rules. The 'clean' libpfring doesn't support them. Instead, it has its own routines to describe filtering rules. I thought it wouldn't be a good idea to force libpfring users to link their applications against libpcap but I didn't want to provide the clean libpfring only either, since it might break existing code, so that's why I decided to offer two groups of packages.
Apart from that, no, I'm not intending to integrate anything into existing packages. I hope I answered your question, if not, don't hesitate to ask again.
Cheers,
-Hilko
--
Regards,
- AJ
Reply to: