OK, so you're just going to use the pf_ring.c from svn and keep userland as it was?
In other words, for my Security Onion distro, I can safely keep our existing 5.5.3 userland package and just update our kernel module package with the pf_ring.c from svn? Thanks! Doug On Wed, Jun 5, 2013 at 11:51 AM, Alfredo Cardigliano <[email protected]> wrote: > Hi Doug > we released 5.5.3 a few days ago, it is likely we refresh that tarball. > > Regards > Alfredo > > On Jun 5, 2013, at 5:45 PM, Doug Burks <[email protected]> wrote: > >> Hi Alfredo, >> >> Thanks for the fix! I did a few quick tests and it appears to be >> working properly. >> >> Will you be releasing a 5.5.4 tarball soon? >> >> Thanks, >> Doug >> >> On Wed, Jun 5, 2013 at 11:33 AM, Alfredo Cardigliano >> <[email protected]> wrote: >>> Hi Doug >>> thank you for the info you reported, as you guessed it was a bug in the >>> fragments handling. >>> Please update from svn, it should be fixed now. >>> >>> Regards >>> Alfredo >>> >>> On Jun 5, 2013, at 4:20 PM, Doug Burks <[email protected]> wrote: >>> >>>> Here's an additional test on 5.5.3 with http_gzip.pcap (with 10 packets): >>>> >>>> - running a single instance of pfcount everything works properly and >>>> /proc/net/pf_ring/info shows: >>>> PF_RING Version : 5.5.3 ($Revision: exported$) >>>> Total rings : 1 >>>> >>>> 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 : 0 >>>> >>>> - running two instances of pfcount with the same clusterId shows no >>>> packets in either pfcount instance and /proc/net/pf_ring/info shows: >>>> PF_RING Version : 5.5.3 ($Revision: exported$) >>>> 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 : 10 >>>> >>>> Any ideas why it's discarding the 10 packets? >>>> >>>> Thanks! >>>> >>>> Doug >>>> >>>> On Wed, Jun 5, 2013 at 8:44 AM, Doug Burks <[email protected]> wrote: >>>>> I repeated these tests on the same Ubuntu VM using PF_RING 5.5.2 >>>>> kernel/userland and clustering works as expected without the packet >>>>> loss seen in 5.5.3. >>>>> >>>>> Perhaps I'm missing something, but it appears that there is a bug in >>>>> the 5.5.3 cluster code. >>>>> >>>>> Can somebody confirm, please? >>>>> >>>>> Thanks! >>>>> >>>>> Doug >>>>> >>>>> >>>>> On Wed, Jun 5, 2013 at 8:06 AM, Doug Burks <[email protected]> wrote: >>>>>> I just did a new test as follows: >>>>>> >>>>>> - started with a fresh installation of Ubuntu 12.04 >>>>>> - downloaded the PF_RING 5.5.3 tarball >>>>>> - compiled and inserted the kernel module >>>>>> - changed pfcount.c to use cluster_per_flow_2_tuple: >>>>>> rc = pfring_set_cluster(pd, clusterId, cluster_per_flow_2_tuple); >>>>>> - compiled pfcount >>>>>> >>>>>> TEST #1 >>>>>> - downloaded http.cap from wireshark.org: >>>>>> http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=http.cap >>>>>> - capinfos reports 43 packets in the file: >>>>>> capinfos -c http.cap >>>>>> File name: http.cap >>>>>> Number of packets: 43 >>>>>> - replayed pcap using: >>>>>> sudo tcpreplay -ieth0 -t http.cap >>>>>> - running a single instance of pfcount results in all 43 packets received >>>>>> - adding a second instance of pfcount with the same clusterId results >>>>>> in all 43 packets received by the first instance >>>>>> - adding a third instance of pfcount results in only 2 packets being >>>>>> seen by the first instance, 7 packets being seen by the second >>>>>> instance, and 0 packets being seen by the third instance >>>>>> >>>>>> TEST #2 >>>>>> - downloaded http_gzip.cap from wireshark.org: >>>>>> http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=http_gzip.cap >>>>>> - capinfos reports 10 packets in the file: >>>>>> capinfos -c http_gzip.cap >>>>>> File name: http_gzip.cap >>>>>> Number of packets: 10 >>>>>> - replayed pcap using: >>>>>> sudo tcpreplay -ieth0 -t http_gzip.cap >>>>>> - running a single instance of pfcount results in all 10 packets received >>>>>> - adding a second instance of pfcount with the same clusterId results >>>>>> in 0 packets received by both instances >>>>>> - adding a third instance of pfcount with the same clusterId results >>>>>> in 0 packets received by all three instances >>>>>> >>>>>> What am I missing? >>>>>> >>>>>> Can somebody please try the tests above and let me know what results you >>>>>> get? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Doug >>>>>> >>>>>> On Tue, Jun 4, 2013 at 7:27 PM, Doug Burks <[email protected]> wrote: >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Doug Burks >>>>>> http://securityonion.blogspot.com >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
