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> 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 > 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
