Hi Moshe there is a similar issue at https://github.com/ntop/PF_RING/issues/94 please continue this discussion there where we keep track of all useful info.
Thank you Alfredo > On 30 May 2016, at 13:44, משה דניאלי <[email protected]> wrote: > > Hi Guys, > > This is my first time posting to this mailing list so I hope I'm doing it > right and not repeating an older question. > > I've been experiencing an issue where a bpf which I supply to a pf_ring > supported tcpdump v-4.1.1 (compiled against libpcap-1.6.2 from the > 6.2.0-stable branch) takes time to be applied, when capturing data in non zc > mode (for example: tcpdump -i eth0 host 1.1.1.1) -> this leads to tcpdump > displaying packets which do not match the bpf. > > This issue is something which libpcap should already take into consideration, > as can be seen here: > https://github.com/ntop/PF_RING/blob/6.2.0-stable/userland/libpcap-1.6.2-ring/pcap-linux.c#L6272 > > <https://github.com/ntop/PF_RING/blob/6.2.0-stable/userland/libpcap-1.6.2-ring/pcap-linux.c#L6272>. > However, that call to setsockopt always return an error ("bad address") > which results in the aforementioned behavior. > > It's important to note that using the same bpf in kernel bypass mode (tcpdump > -i zc:eth0 <zc:eth0> host 1.1.1.1) works perfectly and the bpf is applied > right away. Moreover, executing the standard tcpdump which comes with ubuntu > 14.04, while supplying the same exact bpm works fine as well. > > Can someone please explain this behavior ? > > Thanks in advance, > > Moshe > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
