> On 15 Apr 2015, at 19:10, Amir Kaduri <akadur...@gmail.com> wrote: > > Hi, > > I would like to update that the problem in the tester program was that I > probably didn't add the vlan_id to rule. Once added, the hash rule began to > work.
Ok, that was definitely the problem, vlan-id is part of the hash input (vlan, protocol, src/dst ip, src/dst port). > Also, I would like to refer to the argument "There is no limit to the number > of software hash rules": > I assume that the meaning is that the algorithm doesn't have any limitation, > though, since the rule_id field type is u_int16_t, there is a limit of 64K > hash rules, de-facto. That’s right, we can consider changing the rule_id type if 64K rules is not enough in some use case. Alfredo > > Thanks, > Amir > > On Tue, Apr 14, 2015 at 12:34 PM, Alfredo Cardigliano <cardigli...@ntop.org > <mailto:cardigli...@ntop.org>> wrote: > Hi Amir > yes thank you for the files, I will look at them ASAP. > > Alfredo > >> On 14 Apr 2015, at 11:17, Amir Kaduri <akadur...@gmail.com >> <mailto:akadur...@gmail.com>> wrote: >> >> Hi Alfredo, >> >> I hope you saw what I've sent last week. Any chance that you will take a >> look at it soon? >> >> Thanks, >> Amir >> >> On Fri, Apr 10, 2015 at 11:08 AM, Amir Kaduri <akadur...@gmail.com >> <mailto:akadur...@gmail.com>> wrote: >> Hi Alfredo, >> >> Since the original pcap is huge, I sliced a smaller pcap from it, holding >> 344 packets. >> Link to the tester code (based on pfcount_82599.c): >> https://drive.google.com/file/d/0B10Ms5GOXgCxdXhtRGRoQ1FTYVFDbkFGMkwzVExNRHJXbmt3/view?usp=sharing >> >> <https://drive.google.com/file/d/0B10Ms5GOXgCxdXhtRGRoQ1FTYVFDbkFGMkwzVExNRHJXbmt3/view?usp=sharing> >> >> Link to the pcap file (congtaining 344 packets): >> https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing >> >> <https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing> >> >> Thanks a lot, >> Amir >> >> >> On Wed, Apr 8, 2015 at 4:07 PM, Alfredo Cardigliano <cardigli...@ntop.org >> <mailto:cardigli...@ntop.org>> wrote: >> Hi Amir >> could you provide your patched pfcount and a pcap with the packets matching >> your rule? >> >> Alfredo >> >>> On 08 Apr 2015, at 13:36, Amir Kaduri <akadur...@gmail.com >>> <mailto:akadur...@gmail.com>> wrote: >>> >>> I'm currently in a situation, that no rules work for me whatsoever (same >>> configuration I described earlier), and they did work for me a few day ago. >>> I'm using the pfcount_82599.c tester, and added a single hash rule. The >>> only thing that does work is the default behavior, when using the API >>> pfring_toggle_filtering_policy(pd, 1) (default to allow - packets arrive >>> normally) or pfring_toggle_filtering_policy(pd, 0); (default to drop, no >>> packet arrive to the tester). >>> This is the part of code: >>> ------------------------------------------------------------------------------------------ >>> : >>> rc = pfring_enable_ring(pd); >>> if (rc<0) >>> printf("pfring_enable_ring() failed. rc=%d\n", rc); >>> >>> pfring_toggle_filtering_policy(pd, 1); /* Default to allow */ >>> >>> if (1) { >>> hash_filtering_rule rule; >>> u_int16_t rule_id = 0; >>> >>> memset(&rule, 0, sizeof(hash_filtering_rule)); >>> rule.proto = 6; >>> rule.rule_id = rule_id++; >>> rule.rule_action = dont_forward_packet_and_stop_rule_evaluation; >>> rule.host4_peer_a = ntohl(inet_addr("10.12.150.231")); >>> rule.port_peer_a = 2489; >>> rule.host4_peer_b = ntohl(inet_addr("10.61.12.31")); >>> rule.port_peer_b = 139; >>> rc = pfring_handle_hash_filtering_rule(pd, &rule, 1); >>> if(rc<0) >>> printf("pfring_add_hash_filtering_rule(%d) failed [errno=%d: >>> %s]\n", rule.rule_id, errno, strerror(errno)); >>> else >>> printf("pfring_add_hash_filtering_rule(%d) succeeded\n", >>> rule.rule_id); >>> } >>> ------------------------------------------------------------------------------------------ >>> I don't get any errors when the following code run, but when I bombard the >>> machine >>> with a pcap containing more than 600,000 packets of the specified session >>> that I've expected to be filtered out, >>> packets of it still received at the tester. >>> >>> I'm pretty sure that something goes wrong in pf_ring, but I can't tell what. >>> What is the best way to get debug information, other than reading >>> /var/log/messages? >>> >>> Thanks, >>> Amir >>> >>> >>> On Wed, Apr 8, 2015 at 1:08 PM, Alfredo Cardigliano <cardigli...@ntop.org >>> <mailto:cardigli...@ntop.org>> wrote: >>> >>>> On 05 Apr 2015, at 16:07, Amir Kaduri <akadur...@gmail.com >>>> <mailto:akadur...@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> I think I've made some progress: AFAIU, the packets that I see despite the >>>> rule that supposed to filter them, are packets the receive during the time >>>> interval from rule-set to rule-apply by pfring. >>>> I'll appreciate getting some answers about the following: >>>> 1. If I use the pfring_purge_idle_hash_rules(..) API, is there any way to >>>> know which rules-ids are set and which are vacant? >>>> This is because I have to follow the rules-ids when setting them, but >>>> when I purge them, I don't know which of them were removed. >>> >>> No, unfortunately this is not possible with the current API. >>> >>>> 2. Does this API also purges HW rules? >>> >>> No, It doesn’t. >>> >>>> 3. According to the documentation, I know that HW rules have a limit of >>>> 32,000. What is the limit for hash rules? IS this limit includes the >>>> 32,000 of the HW, or additional to it? >>> >>> There is no limit to the number of software hash rules. >>> >>>> 4. I have a valid rule, but whenever I call >>>> pfring_get_hash_filtering_rule_stats(..), it fails.Any idea why? >>> >>> pfring_get_hash_filtering_rule_stats() should be used with sw rules to get >>> stats from kernel plugins (when used), otherwise there is no stats per rule. >>> >>> Br >>> Alfredo >>> >>>> - I've add the stats code to the pfcount_82599 tester >>>> - In /var/log/messages I see the following message that is probably >>>> originated from ring_setsockopt(): "kernel: [PF_RING] Found rule but >>>> pluginId 0 is not registered" >>>> >>>> Thanks, >>>> Amir >>>> >>>> >>>> On Thu, Apr 2, 2015 at 5:06 PM, Amir Kaduri <akadur...@gmail.com >>>> <mailto:akadur...@gmail.com>> wrote: >>>> Hi Alfredo, >>>> >>>> Thanks for referring to my question. >>>> I hope the following answers: >>>> >>>> [root@CT10K10G]# cat /etc/pf_ring/pfring.conf >>>> min_num_slots=1024 transparent_mode=2 enable_frag_coherence=1 >>>> enable_ip_defrag=1 >>>> >>>> [root@CT10K10G]# cat /proc/net/pf_ring/info >>>> PF_RING Version : 6.0.1 ($Revision: exported$) >>>> Total rings : 0 >>>> >>>> Standard (non DNA) Options >>>> Ring slots : 1024 >>>> Slot version : 15 >>>> Capture TX : Yes [RX+TX] >>>> IP Defragment : Yes >>>> Socket Mode : Standard >>>> Transparent mode : No [mode 2] >>>> Total plugins : 0 >>>> Cluster Fragment Queue : 0 >>>> Cluster Fragment Discard : 0 >>>> >>>> Thanks, >>>> Amir >>>> >>>> >>>> On Thu, Apr 2, 2015 at 4:10 PM, Alfredo Cardigliano <cardigli...@ntop.org >>>> <mailto:cardigli...@ntop.org>> wrote: >>>> Hi Amir >>>> how did you load pf_ring.ko? Can I see the command line? >>>> Please also try using latest code from svn, this helps us debugging the >>>> issue. >>>> >>>> Br >>>> Alfredo >>>> >>>>> On 01 Apr 2015, at 18:22, Amir Kaduri <akadur...@gmail.com >>>>> <mailto:akadur...@gmail.com>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> I’m using PF_RING-6.0.1. >>>>> >>>>> I’m trying to develop an application that runs some algorithm consisting >>>>> on rules. >>>>> >>>>> I made some tests using the “pfcount” tester, and unfortunately, I don’t >>>>> understand the behavior: >>>>> >>>>> I’m running the following command line: “./pfcount -i eth3 -u 2 -v 1 -r >>>>> –m” which AFAIU, adds a wildcard filter for each incoming packet. >>>>> >>>>> If I get it correctly, once a rule was added, I should not expect other >>>>> packets of the same session to receive, and this is not what I’m getting. >>>>> >>>>> For example: >>>>> >>>>> ----------------------------------------------------------------------- >>>>> >>>>> [root@CT10K10G examples]# ./pfcount -i eth3 -u 2 -v 1 -r -m >>>>> >>>>> Adding wildcard filtering rules >>>>> >>>>> Using PF_RING v.6.0.1 >>>>> >>>>> Capturing from eth3 [00:E0:ED:FE:18:19][ifIndex: 11] >>>>> >>>>> # Device RX channels: 6 >>>>> >>>>> # Polling threads: 1 >>>>> >>>>> Dumping statistics on /proc/net/pf_ring/stats/11993-eth3.1074 >>>>> >>>>> 18:52:35.956295950 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 >>>>> <http://10.61.10.9:52311/> -> 10.70.150.108:60189 >>>>> <http://10.70.150.108:60189/>] >>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596843063] >>>>> [caplen=128][len=1522][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>> >>>>> Rule 0 added successfully... >>>>> >>>>> 18:52:35.956301616 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 >>>>> <http://10.61.10.9:52311/> -> 10.70.150.108:60189 >>>>> <http://10.70.150.108:60189/>] >>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596844523] >>>>> [caplen=128][len=650][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>> >>>>> Rule 1 added successfully... >>>>> >>>>> 18:52:35.956303262 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 >>>>> <http://10.61.10.9:52311/> -> 10.70.150.108:60189 >>>>> <http://10.70.150.108:60189/>] >>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596845111] >>>>> [caplen=128][len=1086][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>> >>>>> Rule 2 added successfully... >>>>> >>>>> : >>>>> >>>>> ----------------------------------------------------------------------- >>>>> >>>>> >>>>> How come, that once rule #0 was added for [10.61.10.9:52311 >>>>> <http://10.61.10.9:52311/> -> 10.70.150.108:60189 >>>>> <http://10.70.150.108:60189/>], I still see such packets in the next >>>>> lines? Shouldn’t they be filtered by the rule that just as added? >>>>> >>>>> >>>>> (BTW, when I use the command “./pfcount -i eth3 -u 1 -v 1 -r –m” (i.e. –u >>>>> is 1 rather than 2), the tester uses hash filters, and in this case, I >>>>> get errors: >>>>> >>>>> 18:53:19.052549112 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 >>>>> <http://10.61.10.9:52311/> -> 10.70.150.108:60189 >>>>> <http://10.70.150.108:60189/>] >>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596847159] >>>>> [caplen=128][len=1490][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>> >>>>> pfring_add_hash_filtering_rule(1) failed) >>>>> >>>>> >>>>> Any help will be appreciated. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Amir >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ntop-misc mailing list >>>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>> >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>>> >>>> >>>> _______________________________________________ >>>> Ntop-misc mailing list >>>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> >> _______________________________________________ >> Ntop-misc mailing list >> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> >> >> >> _______________________________________________ >> Ntop-misc mailing list >> Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> > > _______________________________________________ > Ntop-misc mailing list > Ntop-misc@listgateway.unipi.it <mailto:Ntop-misc@listgateway.unipi.it> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > <http://listgateway.unipi.it/mailman/listinfo/ntop-misc> > > _______________________________________________ > Ntop-misc mailing list > Ntop-misc@listgateway.unipi.it > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
_______________________________________________ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
