Dirk, 1. and 3. ok, 2. I need to check, 4. bug, 5. we need to fix as currently we have packaged the nbox gui only for Ubuntu and the rpm package is not yet in perfect shape. We'll fix it
Thanks for reporting the bugs Luca On Mar 18, 2013, at 9:38 AM, Dirk Janssens <[email protected]> wrote: > 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 _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
