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

Reply via email to