Doug I ran a test using curl + pfcount and it is working for me. $ curl testmyids.com
(first instance) $ ./pfcount -i eth0 -c 99 -v 1 -m ... Absolute Stats: [0 pkts rcvd][0 pkts filtered][0 pkts dropped] (second instance) $ ./pfcount -i eth0 -c 99 -v 1 -m ... Absolute Stats: [11 pkts rcvd][11 pkts filtered][0 pkts dropped] Please make sure tx capture is enabled in your test (cat /proc/net/pf_ring/info) Alfredo On Jun 2, 2013, at 7:43 PM, Doug Burks <[email protected]> wrote: > Hi Alfredo, > > Thanks for your suggestion! > > I've changed pfdump.c to use cluster_per_flow_2_tuple: > > if(clusterId > 0) { > rc = pfring_set_cluster(pd, clusterId, cluster_per_flow_2_tuple); > printf("pfring_set_cluster returned %d\n", rc); > } > > I then re-ran the test as follows: > > Replayed a TCP stream with 11 packets onto eth1: > > sudo tcpreplay -i eth1 -M10 testmyids.pcap > sending out eth1 > processing file: testmyids.pcap > Actual: 11 packets (1062 bytes) sent in 0.00 seconds > Rated: inf bps, inf Mbps, inf pps > Statistics for network device: eth1 > Attempted packets: 11 > Successful packets: 11 > Failed packets: 0 > Retried packets (ENOBUFS): 0 > Retried packets (EAGAIN): 0 > > Ran two instances of pfdump on eth1 with same clusterId but neither of > them saw traffic this time: > > sudo ./pfdump -l77 -i eth1 -w instance1.pcap > Using PF_RING v.5.5.3 > Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3] > # Device RX channels: 1 > pfring_set_cluster returned 0 > 1 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 2 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 3 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 4 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 5 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 6 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 7 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 8 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 9 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 10 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 11 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 12 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 13 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > ^CLeaving... > 14 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > > sudo ./pfdump -l77 -i eth1 -w instance2.pcap > Using PF_RING v.5.5.3 > Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3] > # Device RX channels: 1 > pfring_set_cluster returned 0 > 1 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 2 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 3 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 4 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 5 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 6 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 7 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 8 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 9 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 10 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 11 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > 12 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > ^CLeaving... > 13 sec pkts 0 drop 0 bytes 0 | pkts 0 bytes 0 drop 0 > > tcpdump -nnvvr instance1.pcap > reading from file instance1.pcap, link-type EN10MB (Ethernet) > > tcpdump -nnvvr instance2.pcap > reading from file instance2.pcap, link-type EN10MB (Ethernet) > > I've repeated this a few times and get the same result each time. > > Any ideas why cluster_per_flow_2_tuple wouldn't be passing the traffic? > > Thanks! > > Doug > > > On Sun, Jun 2, 2013 at 12:41 PM, Alfredo Cardigliano > <[email protected]> wrote: >> Hi Doug >> the code in pfcount sets the cluster mode to round-robin, >> for flow coherency you should change it to (for instance) >> cluster_per_flow_2_tuple. >> The daq-pfring code sets the cluster mode to cluster_per_flow_2_tuple by >> default. >> >> Best Regards >> Alfredo >> >> Index: pfcount.c >> =================================================================== >> --- pfcount.c (revisione 6336) >> +++ pfcount.c (copia locale) >> @@ -924,7 +924,7 @@ >> #endif >> >> if(clusterId > 0) { >> - rc = pfring_set_cluster(pd, clusterId, cluster_round_robin); >> + rc = pfring_set_cluster(pd, clusterId, cluster_per_flow_2_tuple); >> printf("pfring_set_cluster returned %d\n", rc); >> } >> >> On Jun 2, 2013, at 2:54 PM, Doug Burks <[email protected]> wrote: >> >> I copied the clusterId code from pfcount and pasted into pfdump and >> compiled it. Then tested with a fresh pcap of "curl testmyids.com": >> >> tcpdump -nnr testmyids.pcap >> reading from file testmyids.pcap, link-type EN10MB (Ethernet) >> 12:37:21.846561 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [S], >> seq 2183306783, win 42340, options [mss 1460,sackOK,TS val 13599714 >> ecr 0,nop,wscale 11], length 0 >> 12:37:21.963023 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [S.], seq 3354284181, ack 2183306784, win 64240, options [mss 1460], >> length 0 >> 12:37:21.963070 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 1, win 42340, length 0 >> 12:37:21.963268 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags >> [P.], seq 1:166, ack 1, win 42340, length 165 >> 12:37:21.963423 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.], >> ack 166, win 64240, length 0 >> 12:37:22.083864 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [P.], seq 1:260, ack 166, win 64240, length 259 >> 12:37:22.083906 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 260, win 42081, length 0 >> 12:37:22.084118 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags >> [F.], seq 166, ack 260, win 42081, length 0 >> 12:37:22.085362 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.], >> ack 167, win 64239, length 0 >> 12:37:22.202741 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [FP.], seq 260, ack 167, win 64239, length 0 >> 12:37:22.202786 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 261, win 42081, length 0 >> >> I then started the two instances of pfdump using the same clusterId >> and then replayed the 11 packets with tcpreplay: >> sudo tcpreplay -i eth1 -M10 testmyids.pcap >> sending out eth1 >> processing file: testmyids.pcap >> Actual: 11 packets (1062 bytes) sent in 0.01 seconds >> Rated: 106200.0 bps, 0.81 Mbps, 1100.00 pps >> Statistics for network device: eth1 >> Attempted packets: 11 >> Successful packets: 11 >> Failed packets: 0 >> Retried packets (ENOBUFS): 0 >> Retried packets (EAGAIN): 0 >> >> FIRST INSTANCE OF PFDUMP >> >> sudo ./pfdump -l77 -i eth1 -w instance1.pcap >> Using PF_RING v.5.5.3 >> Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3] >> # Device RX channels: 1 >> pfring_set_cluster returned 0 >> <snip> >> 241 sec pkts 6 drop 0 bytes 500 | pkts 6 bytes 500 drop 0 >> <snip> >> >> tcpdump -nnr instance1.pcap >> reading from file instance1.pcap, link-type EN10MB (Ethernet) >> 12:38:55.886037 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [S], >> seq 2183306783, win 42340, options [mss 1460,sackOK,TS val 13599714 >> ecr 0,nop,wscale 11], length 0 >> 12:38:55.886889 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 3354284182, win 42340, length 0 >> 12:38:55.887325 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.], >> ack 165, win 64240, length 0 >> 12:38:55.887986 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 260, win 42081, length 0 >> 12:38:55.888306 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags [.], >> ack 166, win 64239, length 0 >> 12:38:55.888741 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags [.], >> ack 261, win 42081, length 0 >> >> SECOND INSTANCE OF PFDUMP >> >> sudo ./pfdump -l77 -i eth1 -w instance2.pcap >> Using PF_RING v.5.5.3 >> Capturing from eth1 [00:0C:29:5F:58:D8][ifIndex: 3] >> # Device RX channels: 1 >> pfring_set_cluster returned 0 >> <snip> >> 16 sec pkts 5 drop 0 bytes 826 | pkts 5 bytes 826 drop 0 >> 17 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0 >> 18 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0 >> 19 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0 >> ^CLeaving... >> 20 sec pkts 0 drop 0 bytes 0 | pkts 5 bytes 826 drop 0 >> >> tcpdump -nnr instance2.pcap >> reading from file instance2.pcap, link-type EN10MB (Ethernet) >> 12:38:55.886499 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [S.], seq 3354284181, ack 2183306784, win 64240, options [mss 1460], >> length 0 >> 12:38:55.887129 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags >> [P.], seq 1:166, ack 1, win 42340, length 165 >> 12:38:55.887666 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [P.], seq 1:260, ack 166, win 64240, length 259 >> 12:38:55.888117 IP 172.16.116.128.44229 > 217.160.51.31.80: Flags >> [F.], seq 166, ack 260, win 42081, length 0 >> 12:38:55.888530 IP 217.160.51.31.80 > 172.16.116.128.44229: Flags >> [FP.], seq 260, ack 167, win 64239, length 0 >> >> As you can see, the first instance sees 6 packets and the second >> instance sees 5 packets. Shouldn't all 11 packets in that TCP stream >> be sent to the same instance? >> >> Thanks! >> >> Doug >> >> >> On Sun, Jun 2, 2013 at 7:11 AM, Doug Burks <[email protected]> wrote: >> >> Hi Luca, >> >> I can repeat the test with pfdump when I'm back at my computer, but is there >> something in particular you're looking for that wasn't in the pfcount output >> I provided? Shouldn't all the traffic from that one TCP stream be sent to >> one instance of pfcount? >> >> Thanks, >> Doug >> >> >> On Sunday, June 2, 2013, Luca Deri wrote: >> >> >> Hi >> You're right. We need to add it: you can c&p the code from pfcount in the >> meantime >> >> Luca >> >> On Jun 2, 2013, at 1:54 AM, Doug Burks <[email protected]> wrote: >> >> I have pfdump now but I don't see a cluster-id option. Did you mean >> pfcount? If I run 2 instances of pfcount with the same cluster-id and >> then replay a pcap with 10 packets all belonging to the same TCP >> stream, I get 5 packets being sent to each pfcount instance. >> Shouldn't all 10 packets be sent to 1 instance? >> >> First instance: >> >> sudo ./pfcount -c77 -i eth1 >> <snip> >> ========================= >> Absolute Stats: [5 pkts rcvd][5 pkts filtered][0 pkts dropped] >> Total Pkts=5/Dropped=0.0 % >> 5 pkts - 434 bytes [0.38 pkt/sec - 0.00 Mbit/sec] >> ========================= >> Actual Stats: 5 pkts [1'000.75 ms][5.00 pps/0.00 Gbps] >> ========================= >> >> Second instance: >> >> sudo ./pfcount -c77 -i eth1 >> <snip> >> ========================= >> Absolute Stats: [5 pkts rcvd][5 pkts filtered][0 pkts dropped] >> Total Pkts=5/Dropped=0.0 % >> 5 pkts - 834 bytes [0.62 pkt/sec - 0.00 Mbit/sec] >> ========================= >> Actual Stats: 5 pkts [1'001.39 ms][4.99 pps/0.00 Gbps] >> ========================= >> >> The replayed pcap is just ten packets that result from "curl >> testmyids.com": >> >> tcpdump -nnr testmyids.pcap >> reading from file testmyids.pcap, link-type EN10MB (Ethernet) >> 11:46:11.691648 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [S], seq 3840903154, win 42340, options [mss 1460,sackOK,TS val >> 20137183 ecr 0,nop,wscale 11], length 0 >> 11:46:11.808833 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags >> [S.], seq 2859277445, ack 3840903155, win 5840, options [mss >> 1460,nop,wscale 7], length 0 >> 11:46:11.808854 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [.], ack 1, win 21, length 0 >> 11:46:11.809083 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [P.], seq 1:166, ack 1, win 21, length 165 >> 11:46:11.927518 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags >> [.], ack 166, win 54, length 0 >> 11:46:12.036708 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags >> [P.], seq 1:260, ack 166, win 54, length 259 >> 11:46:12.036956 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [.], ack 260, win 21, length 0 >> 11:46:12.037206 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [F.], seq 166, ack 260, win 21, length 0 >> 11:46:12.154641 IP 217.160.51.31.80 > 192.168.111.111.50154: Flags >> [F.], seq 260, ack 167, win 54, length 0 >> 11:46:12.154888 IP 192.168.111.111.50154 > 217.160.51.31.80: Flags >> [.], ack 261, win 21, length 0 >> >> Any ideas? >> >> Thanks, >> Doug >> >> On Sat, Jun 1, 2013 at 5:48 PM, Doug Burks <[email protected]> wrote: >> >> On Sat, Jun 1, 2013 at 10:24 AM, Luca Deri <[email protected]> wrote: >> >> Hi Doug >> >> On Jun 1, 2013, at 6:59 AM, Doug Burks <[email protected]> wrote: >> >> Hello all, >> >> I recently packaged PF_RING 5.5.3 for my Security Onion distro: >> >> http://securityonion.blogspot.com/2013/05/pfring-553-packages-now-available.html >> >> Perhaps I'm missing something, but I'm seeing some behavior I don't >> remember seeing in 5.5.2 or previous versions of PF_RING. >> >> Here are my testing parameters: >> - starting off with a good test, if I run just one instance of snort, >> I get an alert from rule 2100498 for EACH time I run "curl >> testmyids.com" >> - if I increase to two instances of snort with the same cluster-id, I >> get NO alerts when running "curl testmyids.com" >> - if I set the daq clustermode to 2, I get NO alerts when running >> "curl > _______________________________________________ >> >> >> 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 >> >> >> >> >> -- >> Doug Burks >> http://securityonion.blogspot.com >> >> >> >> >> -- >> Doug Burks >> http://securityonion.blogspot.com >> _______________________________________________ >> 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 >> > > > > -- > Doug Burks > http://securityonion.blogspot.com > _______________________________________________ > 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
