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
