Doug I don't think the support for packet injection is going to interfere your test. Could you try sending packets from another interface? Could you provide me the original pcap you are using and the produced pcaps?
Thanks Alfredo On Jun 2, 2013, at 11:40 PM, Doug Burks <[email protected]> wrote: > I see this in the Changelog: > > - Support for injecting packets to the stack > > Is it possible that this change could have an impact on my test since > I'm using tcpreplay? > > Thanks, > Doug > > On Sun, Jun 2, 2013 at 2:59 PM, Doug Burks <[email protected]> wrote: >> cat /proc/net/pf_ring/info >> >> PF_RING Version : 5.5.3 ($Revision: $) >> Total rings : 2 >> >> Standard (non DNA) Options >> Ring slots : 4096 >> Slot version : 15 >> Capture TX : Yes [RX+TX] >> IP Defragment : No >> Socket Mode : Standard >> Transparent mode : Yes [mode 0] >> Total plugins : 0 >> Cluster Fragment Queue : 0 >> Cluster Fragment Discard : 16830 >> >> I've tried a few different pcaps, some of them are like my testmyids >> sample in that no packets make it to pfdump, others work perfectly, >> while for others it looks like only some of the packets are making it >> into pfdump: >> >> sudo tcpreplay -i eth1 -M10 >> /opt/samples/markofu/honeynet_suspicious-time.pcap >> sending out eth1 >> processing file: /opt/samples/markofu/honeynet_suspicious-time.pcap >> Actual: 745 packets (293958 bytes) sent in 0.32 seconds >> Rated: 918618.8 bps, 7.01 Mbps, 2328.12 pps >> Statistics for network device: eth1 >> Attempted packets: 745 >> Successful packets: 745 >> Failed packets: 0 >> Retried packets (ENOBUFS): 0 >> Retried packets (EAGAIN): 0 >> >> 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 257 drop 0 bytes 81262 | pkts 257 bytes 81262 drop 0 >> 12 sec pkts 136 drop 0 bytes 72265 | pkts 393 bytes 153527 drop 0 >> 13 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 drop 0 >> 14 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 drop 0 >> 15 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 drop 0 >> 16 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 drop 0 >> 17 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 drop 0 >> ^CLeaving... >> 18 sec pkts 0 drop 0 bytes 0 | pkts 393 bytes 153527 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 21 drop 0 bytes 6352 | pkts 21 bytes 6352 drop 0 >> 11 sec pkts 15 drop 0 bytes 3640 | pkts 36 bytes 9992 drop 0 >> 12 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> 13 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> 14 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> 15 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> 16 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> ^CLeaving... >> 17 sec pkts 0 drop 0 bytes 0 | pkts 36 bytes 9992 drop 0 >> >> What else can I test? >> >> Thanks! >> >> Doug >> >> On Sun, Jun 2, 2013 at 2:07 PM, Alfredo Cardigliano >> <[email protected]> wrote: >>> 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 >> >> >> >> -- >> 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
