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
