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> 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 > > Link to the pcap file (congtaining 344 packets): > > 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> > 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> 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 >> > wrote: >> >>> >>> On 05 Apr 2015, at 16:07, Amir Kaduri <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> 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> 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> 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 -> >>>>> 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 -> >>>>> 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 -> >>>>> 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 -> >>>>> 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 -> >>>>> 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 >>>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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
