Hi Jason the code in svn contains some fixes for kernel 3.13, thus I cannot tell you 6.0.1 supports kernel 3.13.
Alfredo On 20 Jul 2014, at 19:25, dn1nj4 <[email protected]> wrote: > Hey Alfredo, > > I did not. I generally avoid delopying code in production that has not been > released as Stable. So does 6.0.1 Stable not support Kernel 3.13? > > Thanks! > Jason > >> Date: Fri, 18 Jul 2014 17:35:09 +0200 >> From: Alfredo Cardigliano <[email protected]> >> To: [email protected] >> Subject: Re: [Ntop-misc] PF_RING 6.0.1/Linux Kernel 3.13 Problems >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=us-ascii >> >> Hi Jason >> code from SVN should support 3.13, did you try updating from SVN? >> >> Alfredo >> >>> On 18 Jul 2014, at 15:21, Jason <[email protected]> wrote: >>> >>> Hello all, >>> >>> Yesterday I upgraded a number of my systems to the Linux 3.13 kernel and >>> PF-RING from 5.6.2 to 6.0.1. I have encountered several significant >>> problems after the upgrades. >>> >>> First, one of my systems which was collecting around 900Mbps began >>> recording only 1Mbps. Rolling back just the PF_RING 5.6.2 kernel module >>> (compiled against the 3.13 kernel) fixed this problem and capture levels >>> returned to normal. >>> >>> Second, a different system running several capture processes is recording >>> packets filtered with "port 25" as ethernet packets only. It appears as >>> though the IP and TCP headers are being stripped, but the ethernet and tcp >>> payload are being stored. The only way I was able to get this working >>> again was to roll back to an old 3.2 kernel, the PF_RING 5.6.2 kernel >>> module AND the the PF_RING libpcap library. This behavior appeared with >>> every packet capture tool I tried (snort, tcpdump, bro, etc). >>> >>> Is the 3.13 linux kernel officially supported? Is there something else >>> that might cause these strange errors? >>> >>> In all cases I was running transparent mode 0 with the vanilla NIC drivers. >>> >>> Thanks in advance, >>> Jason >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 18 Jul 2014 15:50:29 +0000 >> From: Mike Patterson <[email protected]> >> To: "<[email protected]>" >> <[email protected]> >> Subject: Re: [Ntop-misc] Snort, DNA DAQ, bpf >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="Windows-1252" >> >> Oh! Sorry, I didn't understand what you were asking. Will follow up, yeah. >> >> thanks! >> >> Mike >> >>> On Jul 18, 2014, at 11:39, "Alfredo Cardigliano" <[email protected]> >>> wrote: >>> >>> 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 >> >> >> ------------------------------ >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> End of Ntop-misc Digest, Vol 121, Issue 17 >> ****************************************** > _______________________________________________ > 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
