On 05/06/2015 11:52 PM, Daniel Borkmann wrote:
Sorry for the late answer.
On 05/01/2015 02:53 PM, [email protected] wrote:
...
Interesting, lets say if you use --fanout-type lb, would that make a difference?
This should round robin each packet between these 3 processes, so you should
definitely see something unless we have a bug. ;) Let me know, so we can look
further ...
no change if using --fanout-type lb. I see all 3 instances run and show similar
CPU % in top, but only last file seems to be on my SSD.
BTW, --fanout-type qm returns "$ Cannot set fanout ring mode!", that's why I
switched to type cpu. ( considering I use irq affinity script to lock Rx queues to
certain CPUs and also I lock netsniff-ng, I guess it doesn't matter which one I use cpu
or qm )
The qm won't work in your case since your kernel is too old.
So I was just using the following:
netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag --ring-size
128MiB --bind-cpu 0 --notouch-irq --silent \
--in lo --out /tmp/netcapture/ --prefix "a." --interval 60sec &
netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag --ring-size
128MiB --bind-cpu 1 --notouch-irq --silent \
--in lo --out /tmp/netcapture/ --prefix "b." --interval 60sec &
netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag --ring-size
128MiB --bind-cpu 2 --notouch-irq --silent \
--in lo --out /tmp/netcapture/ --prefix "c." --interval 60sec &
And doing a ping 127.0.0.1, gives me pcap files in /tmp/netcapture/ with all
three {a,b,c}.
prefixes; plus after 60sec they start a new one.
I've also tried two instances dumping to two different files with various
fanout-types,
they seem to work as expected. That means that fanout in general seems to
function.
The only issue (as I don't know what traffic you're seeing) could be that your
rxhash
always falls into fanout member with that prefix, strange.
Does the above example work for you on loopback? If you have two instances in
the same
group outputting to a normal pcap file with rnd, do you both files get written?
Also fanout-type by hash on physical interface looks correct in my case, f.e.:
netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag
--ring-size 128MiB --bind-cpu 0 --notouch-irq --silent \
--in wlp2s0b1 --out /tmp/netcapture/ --prefix "a." --interval 60sec
&
netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag
--ring-size 128MiB --bind-cpu 1 --notouch-irq --silent \
--in wlp2s0b1 --out /tmp/netcapture/ --prefix "b." --interval 60sec
&
netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag
--ring-size 128MiB --bind-cpu 2 --notouch-irq --silent \
--in wlp2s0b1 --out /tmp/netcapture/ --prefix "c." --interval 60sec
&
E.g. if I'm running ping 8.8.8.8, then that /only/ lands with some other stuff
in c's pcap,
which is as expected.
Cheers,
Daniel
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
