Hi Mike
as I said, if it is possible please provide us access to your machine (feel 
free to contact me directly)

Alfredo

On 16 Jul 2014, at 19:25, Mike Patterson <[email protected]> wrote:

> Sure, just let me know what I should do and I’ll do it. :) The sooner I can 
> fix this, the sooner I can release my older hardware to do other things.
> 
> Mike
> 
> On Jul 16, 2014, at 12:47 PM, Alfredo Cardigliano <[email protected]> 
> wrote:
> 
>> Hi Mike
>> bpf support in the daq-dna is available since r2679, so it is supposed to 
>> work with your version.
>> Do we have a chance to debug this on your machine?
>> 
>> Alfredo
>> 
>> On 16 Jul 2014, at 17:51, Mike Patterson <[email protected]> wrote:
>> 
>>> Hi all,
>>> 
>>> On my previous Snort sensor, built on an Endace DAG, I had a BPF for Snort 
>>> to exclude certain types of traffic. The BPF worked fine; Snort 2.9.5.1 and 
>>> some previous versions.
>>> 
>>> When I changed my Snort sensor to an X520 + PF_RING / DNA, that BPF stopped 
>>> working. I can tell that Snort is loading it - it says as much in syslog - 
>>> but it will still happily alert on traffic matching those exclusions.
>>> 
>>> I’ve tried various iterations (I posted more detail on the snort-users list 
>>> if anybody wants to look, or I can re-paste it here), but succinctly:
>>> 
>>> 1) I don’t think it’s Snort itself - it did work on my previous platform. I 
>>> tried differing versions of Snort just to be sure - 2.9.5.1, 2.9.6.0, 
>>> 2.9.6.1.
>>> 
>>> 2) I built tcpdump from the PF_RING distribution, and handed it the same 
>>> BPF - it worked just fine, or at least, tcpdump didn’t complain about the 
>>> BPF. I did a trivial test:
>>> tcpdump -i dna1@0 -n -w test.lpc not net 10.0.0.1/24
>>> tcpdump -r test.lpc net 10.0.0.1/24
>>> and got the expected output (nothing). So I *think* that this means libpcap 
>>> (also built from PF_RING distribution) is fine.
>>> 
>>> 3) Following the advice and some other troubleshooting on snort-users, I 
>>> verified that I’m not seeing this traffic as a result of GRE tunnelling or 
>>> VLAN tags.
>>> 
>>> Versions:
>>> PF_RING 6.0.1
>>> pfring-daq-module-dna_r2795 (I’d also tried pfring-daq-module-dna_r2521)
>>> 
>>> The Intel-based machine is not yet in production, so I can fairly easily 
>>> try anything people might suggest.
>>> 
>>> Other details of my environment:
>>> RHEL 6.5
>>> Intel X520 NIC:
>>> 06:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter 
>>> (rev 01)
>>> 
>>> /proc/net/pf_ring/info is:
>>> PF_RING Version          : 6.0.1 ($Revision: exported$)
>>> Total rings              : 0
>>> 
>>> Standard (non DNA) Options
>>> Ring slots               : 16384
>>> Slot version             : 15
>>> Capture TX               : No [RX only]
>>> IP Defragment            : Yes
>>> Socket Mode              : Standard
>>> Transparent mode         : No [mode 2]
>>> Total plugins            : 0
>>> Cluster Fragment Queue   : 0
>>> Cluster Fragment Discard : 0
>>> 
>>> The X520 plugs into a tool port on an Arista 7150S. The DAG plugs into 
>>> another tool port on the same switch; both tool ports are in the same 
>>> aggregation group, so they should be getting identical data.
>>> 
>>> I *do* have the option of applying the BPF on the Arista switch itself, 
>>> although I’d rather avoid that if I can.
>>> 
>>> Thanks in advance for any advice/debugging suggestions/etc.
>>> 
>>> Mike
>>> 
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> [email protected]
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>> 
>> _______________________________________________
>> Ntop-misc mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
> 
> _______________________________________________
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Reply via email to