New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BPF Filters not working #94
Comments
I am seeing the same issue. I am able to BPF filter non-pfring interfaces, but more specifically I cannot filter on pfring/zc interfaces.
strace output:
|
Working with both standard and zc interfaces/queues on a similar system in our lab, need to investigate more.. do you have any packet encapsulation perhaps? |
Verified with my network engineer that the traffic i am setting in the BPF would not be encapsulated. Also when i run tcpdump without any filters it dumps to stdout without any issues. |
I'm getting the same feed on the RHEL box sent to another sensor running Ubuntu 12.04 and BPF seems to be working there. RHEL PF_RINGPF_RING Version : 6.3.0 (dev:d568ce59908fd0021ec7910b0563db191301e61c) Standard (non DNA/ZC) Options Ubuntu PF_RINGPF_RING Version : 6.3.0 (dev:6c796df2a032d00202d590485124b67cffea3ef6) Standard (non DNA/ZC) Options What would be the best way to go about debugging this? |
@jimhranicky i'm confused are you saying you're seeing the same thing on the RHEL box and not the ubuntu? |
Correct, with taps from the same source RHEL BPF filters are not working while the ubuntu ones are. |
attached are 2 strace's of tcpdump. One on a physical interface that works. The other on a pfring interface. physical interface (working): physical-int-tcpdump-strace.txt pfring interface (broken): pfring-int-tcpdump-strace.txt |
Hi guys
|
@cardigliano yes that is correct on my end. |
A few updates:
|
@cardigliano I will email you privately and we can arrange a time to do a remote session. |
I have the same issue here. Tcpdump is working right, but any bpf filters in nprobe are not working at all. No encapsulation, and traffic is coming from an optic tap. Ubuntu 16.04. When runing "nprobe -f host 127.0.0.1 -i ens1f1 -b 1", I have seen this logs in the initialization: 09/Jun/2016 15:53:44 [pro/pf_ring.c:377] Initializing PF_RING socket on device ens1f1.. I can provide you any needed additional information. Regards. |
@vbarahona please use quotation marks: -f "host 127.0.0.1" |
Thanks @cardigliano that works. :-) Suggestion: there is not mention of needs of quotation marks in the bpf filter nor man page nor "nProbe Users Guide" and since are not need when using tcpdump it should be notice in documentation. |
I just yum updated to 3.10.0-327.18.2.el7.x86_64 and installed the rpms from ntop.org . I'm still getting the same behavior. There does seem to be a difference in the behavior of the libraries as reported by ltrace : Preload the pf_ring libpcap: % LD_PRELOAD=/usr/local/lib/libpcap.so.1 ltrace -e '@libpcap.so' tcpdump -i enp4s0 -nn -c 10 'port 22' 2>&1 | grep bpf Normal tcpdump: % ltrace -e '@libpcap.so' tcpdump -i enp4s0 -nn -c 10 'port 22' 2>&1 | grep bpf
It doesn't seem that the pf_ring libpcap calls bpf_filter_with_aux_data . Does |
@jimhranicky thank you for the hint. Do you experience the same issue using the tcpdump in pf_ring, compiled with static libpcap (not the system tcpdump with LD_PRELOAD)? |
Yes: % ldd /opt/pf/sbin/tcpdump % strings - /opt/pf/sbin/tcpdump | grep pfring | head -20 % /opt/pf/sbin/tcpdump -i enp4s0 -nn -c 10 'port 22' | perl -pe 's,\d+.\d+.\d+.\d+,XX.XX.XX.XX,g' |
Rebuiling PF_RING to version 6.5.0 resolved this issue for me. Many thanks @cardigliano for the assistance. |
@jimhranicky could you also try updating to latest dev code, or providing me access to the machine? Thank you |
Sorry, this got sent to my spam folder, will try updating soon. Jim On 07/13/2016 04:28 AM, Alfredo Cardigliano wrote:
|
Same behavior for 6.5.0: Jul 22 14:07:51 pdump kernel: [PF_RING] Welcome to PF_RING 6.5.0 ($Revision: dev:8f298fcf9e4ccc33c2bf46bb94f00d0d46dd Do you want to try a webex or something? |
@jimhranicky please send to cardigliano@ntop.org the details for connecting to your machine (preferably ssh, webex also works, send me your availability in the latter case). Thank you. |
I ran gdb on both the pf tcpdump and the latest tcpdump from tcpdump.org and it seems that tcpdump-4.7.4/pcap-linux:4536
Tracing through the pf_ring tcpdump, I see that variable getting unset:
I don't know if that's what's causing the problem. |
Ok, seeing as how this may be a problem with the kernel filters, I set enable_debug = 1 in pf_ring.c . Jul 28 10:27:18 pdump kernel: [PF_RING] ring_create() [pid=8699] |
"Filter failed" actually is not a failure, it means that the bpf filter is filtering out packets (I will change the message). However this means that the filter is somehow working (at least it is filtering something). What is strange is that vanilla tcpdump is not using kernel filtering on your OS.. |
I don't know if this is useful, but there's a difference between using -i and -i zc: : Without BPF : /opt/pf/sbin/tcpdump -i enp4s0 -nns0 -c 1000000 -w /dev/nullWarning: Kernel filter failed: Bad address /opt/pf/sbin/tcpdump -i zc:enp4s0 -nns0 -c 1000000 -w /dev/nulltcpdump: listening on zc:enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes With BPF: (filter fails) /opt/pf/sbin/tcpdump -i enp4s0 -nns0 -c 5 'port 22' | perl -pe 's,(\d+.\d+.\d+.\d+),XX.XX.XX.XX,g'tcpdump: verbose output suppressed, use -v or -vv for full protocol decode (filter succeeds) /opt/pf/sbin/tcpdump -i zc:enp4s0 -nns0 -c 5 'port 22' | perl -pe 's,(\d+.\d+.\d+.\d+),XX.XX.XX.XX,g'tcpdump: verbose output suppressed, use -v or -vv for full protocol decode |
@jimhranicky @cardigliano Have there been any further developments on this issue? We are encountering the same problem (BPF filters not working) with 6.4.1 and 6.5.0 on Ubuntu 16.04.1. |
@sonysouthbeach do you have the same issue (filter not working) all the time during a capture session, or just at the beginning of the session (let's say for a couple of seconds)? |
@cardigliano First couple of seconds only. |
This was due to libpcap activating the socket before setting the filter. Please update the code from github dev (or wait for the nightly build) and let us know. Thank you. |
Will do! Thanks so much for the quick response. |
@cardigliano We were able to confirm that this fixed the BPF filtering problem. Thanks again. |
Great, thank you |
With normal tcpdump :
% tcpdump -i enp4s0 -nn -c 10 'port 22'
tcpdump: WARNING: enp4s0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp4s0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:50:00.338419 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.60212: Flags [.], seq 2354062218:2354063678, ack 800994694, win 2380, length 1460
17:50:00.338438 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.64833: Flags [P.], seq 652703376:652703456, ack 606406036, win 5657, length 80
17:50:00.338466 IP XX.XX.XX.XX.64833 > XX.XX.XX.XX.22: Flags [.], ack 0, win 255, length 0
17:50:00.338482 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.60212: Flags [.], seq 1460:8760, ack 1, win 2380, length 7300
17:50:00.339772 IP XX.XX.XX.XX.60212 > XX.XX.XX.XX.22: Flags [P.], seq 1:69, ack 32872, win 10519, length 68
17:50:00.339786 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.64833: Flags [P.], seq 480:560, ack 1, win 5657, length 80
17:50:00.339789 IP XX.XX.XX.XX.64833 > XX.XX.XX.XX.22: Flags [.], ack 480, win 253, length 0
17:50:00.339953 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.64833: Flags [P.], seq 560:640, ack 1, win 5657, length 80
17:50:00.340376 IP XX.XX.XX.XX.22 > XX.XX.XX.XX.64833: Flags [P.], seq 640:720, ack 1, win 5657, length 80
17:50:00.340382 IP XX.XX.XX.XX.64833 > XX.XX.XX.XX.22: Flags [.], ack 640, win 252, length 0
10 packets captured
895 packets received by filter
795 packets dropped by kernel
With PF_RING's tcpdump :
RH Ver : 3.10.0-327.13.1.el7.x86_64
PF_RING Ver :
The text was updated successfully, but these errors were encountered: