Good morning Doug I received the pcap but I was traveling, I will check them asap
Thanks Alfredo On Jun 4, 2013, at 12:30 PM, Doug Burks <[email protected]> wrote: > Good morning Alfredo, > > Just wanted to follow up and confirm that you received the 5 pcaps I > sent off-list yesterday. > > Is there anything else I can provide to help troubleshoot this issue? > > Thanks! > > Doug > > > On Mon, Jun 3, 2013 at 7:24 AM, Doug Burks <[email protected]> wrote: >> On Mon, Jun 3, 2013 at 3:39 AM, Alfredo Cardigliano >> <[email protected]> wrote: >>> Doug >>> I don't think the support for packet injection is going to interfere your >>> test. >>> Could you try sending packets from another interface? >> >> I've confirmed this behavior using tcpreplay in a VM and also on a >> physical sensor connected to a tap. >> >>> Could you provide me the original pcap you are using and the produced pcaps? >> >> Sent off-list. >> >> Please let me know if there is anything else I can provide to help >> troubleshoot this issue. >> >> Thanks! >> >> Doug >>> >>> 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 >> >> >> >> -- >> 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
