madhuresh wrote:
So the final question is "Is there any alternative way (consider
operating system to be linux) apart from BPF code for kernel level
filtering" ?
To my understanding there can be two possibilties:
1. A new interface (say XYZ0) where only filtered packets come from
driver/kernel side. Then libpcap will simply read it up (using
PF_PACKET ??).
2. Netlink socket between libpcap and driver code.
Neither of those give you kernel-level filtering. You would have to add
kernel-level filtering code somewhere - and if what you add is a socket
filter, you have the same limitation.
Furthermore, if the goal is to use this with libpcap, your filter will
be a BPF program, so you'd have to have a BPF filter interpreter with a
greater limit on the number of BPF instructions than, for example, the
4096-instruction limit in the 2.6.17.3 kernel.
I.e., it's not as if those options will magically make the problem go away.
Can you suggest which option is better
You forgot option 3:
3. Raise the limit on the maximum number of BPF instructions.
You're going to have to add stuff to, or change stuff in, the kernel to
implement this *anyway*, so you might as well just boost the maximum
number of BPF instructions and not have to change libpcap *at all*.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.