Chris
application name and proc device name with DNA clusters have been fixed, please 
update from svn.

Regards
Alfredo

On Jul 24, 2012, at 6:09 PM, Alfredo Cardigliano <[email protected]> wrote:

> Chris
> thank you also for your patch
> 
> On Jul 24, 2012, at 6:01 PM, Chris Wakelin wrote:
> 
>> Funnily enough, I'd just done something similar for libpcap:
>> 
>> --- pcap-linux.c.orig   2012-07-11 22:26:50.140614153 +0100
>> +++ pcap-linux.c        2012-07-24 11:32:29.546820579 +0100
>> @@ -1165,6 +1165,7 @@
>>         /* Code courtesy of Chris Wakelin <[email protected]> */
>>         char *clusterId;
>>         int flags = 0;
>> +         char *appname;
>> 
>>         if(handle->opt.promisc) flags |= PF_RING_PROMISC;
>>         if(getenv("PCAP_PF_RING_DNA_RSS")) flags |=
>> PF_RING_DNA_SYMMETRIC_RSS;
>> @@ -1179,6 +1180,10 @@
>>               else
>>                 pfring_set_cluster(handle->ring, atoi(clusterId),
>> cluster_round_robin);
>> 
>> +         if(appname = getenv("PCAP_PF_RING_APPNAME"))
>> +           if(strlen(appname) > 0 && strlen(appname) <= 32)
>> +             pfring_set_application_name(handle->ring, appname);
>> +
>>           pfring_set_poll_watermark(handle->ring, 1 /* watermark */);
>>           handle->ring->dna.dna_rx_sync_watermark = 0; /* trick
>> (otherwise tshark wouldn't work with DNA) */
>>         } else
>> 
>> though it might make sense to try and get the appname from the
>> commandline or thread name if none is specified otherwise.
>> 
>> I then found it doesn't seem to work with DNA clusters (at least in
>> PF_RING 5.4.4). I spent a while scratching my head and then realised
>> that Suricata wasn't managing to set the name either and it was calling
>> pfring_set_application_name() directly.
>> 
>> On a related note, with DNA clusters, I can't make sense of the device
>> names in /proc/net/pfring/<pid>-<interface>.nnn; For my DNA cluster
>> dnacluster:1 (using dna0 as the source) I've got some appearing as
>> <pid>-dna0.nnn and others as <pid>-dna1.nnn with pfdnacluster_master
>> itself appearing as expected as <pid>-dna0.nnn
>> 
>> Is this expected behavior?
> 
> This is going to our TODO queue, I will check also it. Thanks.
> 
> Alfredo
> 
>> 
>> Best Wishes,
>> Chris
>> 
>> On 24/07/12 16:42, Alfredo Cardigliano wrote:
>>> available in svn, thank you
>>> 
>>> Alfredo
>>> 
>>> On Jul 24, 2012, at 5:16 PM, [email protected] wrote:
>>> 
>>>> Hi,
>>>> 
>>>> pls consider the following little patch that sets the application name
>>>> in the daq_pfring module:
>>>> 
>>>> 
>> 
>> -- 
>> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
>> Christopher Wakelin,                           [email protected]
>> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
>> Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094
>> _______________________________________________
>> Ntop-dev mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> 

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

Reply via email to