I pulled new code from svn, compiled and inserted the new kernel module, and verified that I get the same results.
I see this in the 5.5.3 Changelog: - Added ability to balance tunneled/fragmented packets with the cluster Is it possible that this change is affecting the hashing mechanism? Anything else I can try? Thanks, Doug On Tue, Jun 4, 2013 at 6:40 AM, Alfredo Cardigliano <[email protected]> wrote: > 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 -- Doug Burks http://securityonion.blogspot.com _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
