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
