Hi,
I'm not sure if this is the place to report these issues. If not, please inform me of the proper channels :-) All remarks are based on nProbe-6.12.130317-3298.x86_64.rpm and pfring-5.5.3-6073.x86_64.rpm. 1. There is a small typo in the verbose output of nProbe: [nprobe.c:1860] Fragment queue lenght: 60 -> should be 'length' 2. The current Mb/sec traffic indicator is slowly drifting to an incorrect much-to-high value. When starting nProbe (nprobe -b1 -w 16777216 -e0 -i dna1), I get correct values in the beginning. After running 10 hours, I get the following result: [nprobe.c:2017] Current traffic: [151.031 K pps][6 Gb/sec] After running 24 hours, I get the following result: [nprobe.c:2017] Current traffic: [101.000 K pps][9 Gb/sec] When I restart nProbe, I get correct results again: [nprobe.c:2017] Current traffic: [97.713 K pps][762 Mb/sec] Any idea what is causing this? 3. It appears that once the traffic is high enough, the speed counter switches to Gbit/sec with only 1 significant digit (e.g. 6 Gb/sec). Is it possible to have a few more significant digits to get a more accurate reading? Or maybe keep the counter unit in Mb/sec? 4. Since I use the rpm packages, I would like to use the init scripts provided by the package. However, ' /etc/init.d/pf_ring' tries to load the pf_ring kernel module from /lib/modules/$KERNEL_VERSION/kernel/net/pf_ring/pf_ring.ko instead of the location where the package puts the file (/usr/local/pfring/kernel/pf_ring.ko). I now had to modify the init script, but a more clean solution would be to look for the pf_ring module in both locations (with a preference for the lib/modules location). This solution would also provide backward compatibility with earlier versions. 5. The pf_ring init scripts also look for driver config in ' /etc/pf_ring/dna-$D.conf'. However, the rpm package does not create either /etc/pf_ring or dummy .conf (dna-ixgbe.conf, dna-igb.conf and dna-e1000e.conf) files. I think the rpm package would be more standards compliant if it would do so. Also, the way the .conf files are used, is not as versatile as it could be (especially the possibility of comments in the conf file). A very common way to do this, is to source the config into the executing script. E.g.: test.conf contains: # This is a comment describing the function and possible values of PARAM PARAM='RSS=1,1,1,1' The init script can use it simply with: #!/bin/bash . test.conf echo $PARAM; I'm just wondering if there's a specific reason why the current 'cat' approach was used? Kind regards, Dirk Janssens _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
