Re: [Ntop-misc] Possible bug in SW hash rule API
After using latest code from git, the problem is indeed solved! Thanks a lot Alfredo! On Wed, May 13, 2015 at 1:43 AM, Alfredo Cardigliano cardigli...@ntop.org wrote: Hi Amir the commit below should solve your issue, please pull latest code from git Alfredo https://github.com/ntop/PF_RING/commit/b67a6f46a06e68f2bb6cc53e9d452cc2cbe5f18f On 12 May 2015, at 12:15, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, The application itself is one of the example application provided by pf_ring itself called pfcount. Here is a decription of he steps done: Download pf_ring 6.0.3 and compile it 64bit (including drivers' PF_RING_aware subdirectory). (need to fix a small bug in pfcount.c by adding break; at line 799, so that it will be possible to use the option -u). On production env, suppose current working directory is PF_RING's source root. From this point, the commands are: rmmod ixgbe rmmod pf_ring insmod ./kernel/pf_ring.ko insmod ./drivers/PF_RING_aware/intel/ixgbe/ixgbe-3.22.3-zc/src/ixgbe.ko ./userland/examples/pfcount -i eth3 -w 1 -m -v 1 -u 1 You can replay the following pcap that contains 344 packets: https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing You should see that pfcount stops showing packets from this pcap (since the hash filter is applied), but on the other hand, it shows the following message (especially the first one): 13:02:28.616480105 [RX][if_index=29][00:30:05:4B:19:2C - 00:01:02:03:04:05] [vlan 12] [IPv4][10.12.150.231:2489 - 10.61.12.31:139] [l3_proto=TCP][hash=340372828][tos=0][tcp_seq_num=3256921511] [caplen=128][len=242][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=58] pfring_add_hash_filtering_rule(1) failed This error message indicates that pfring_add_hash_filtering_rule() returned failure in userland. Note that despite the returned error in userland, the hash rule has been added successfully in the kernel. Thanks, Amir On Mon, May 11, 2015 at 8:02 PM, Alfredo Cardigliano cardigli...@ntop.org wrote: Hi Amir could you provide a sample application, or a code snippet, we can use to reproduce the issue? Thank you Alfredo On 11 May 2015, at 10:52, Amir Kaduri akadur...@gmail.com wrote: Hi, I'm experiencing a possible bug in the API pfring_handle_hash_filtering_rule(), when adding a rule. The API return -1 (failure) although the hash rule has been added successfully. I experience it in versions 6.0.2 and 6.0.3. In version 6.0.1 it works fine. Can anyone please confirm that there is a bug? If yes, can I have a patch for it, or even a quick-and-dirty explanation on how to solve it? Thanks, Amir ___ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: [Ntop-misc] Possible bug in SW hash rule API
Hi Amir the commit below should solve your issue, please pull latest code from git Alfredo https://github.com/ntop/PF_RING/commit/b67a6f46a06e68f2bb6cc53e9d452cc2cbe5f18f On 12 May 2015, at 12:15, Amir Kaduri akadur...@gmail.com wrote: Hi Alfredo, The application itself is one of the example application provided by pf_ring itself called pfcount. Here is a decription of he steps done: Download pf_ring 6.0.3 and compile it 64bit (including drivers' PF_RING_aware subdirectory). (need to fix a small bug in pfcount.c by adding break; at line 799, so that it will be possible to use the option -u). On production env, suppose current working directory is PF_RING's source root. From this point, the commands are: rmmod ixgbe rmmod pf_ring insmod ./kernel/pf_ring.ko insmod ./drivers/PF_RING_aware/intel/ixgbe/ixgbe-3.22.3-zc/src/ixgbe.ko ./userland/examples/pfcount -i eth3 -w 1 -m -v 1 -u 1 You can replay the following pcap that contains 344 packets: https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing You should see that pfcount stops showing packets from this pcap (since the hash filter is applied), but on the other hand, it shows the following message (especially the first one): 13:02:28.616480105 [RX][if_index=29][00:30:05:4B:19:2C - 00:01:02:03:04:05] [vlan 12] [IPv4][10.12.150.231:2489 http://10.12.150.231:2489/ - 10.61.12.31:139 http://10.61.12.31:139/] [l3_proto=TCP][hash=340372828][tos=0][tcp_seq_num=3256921511] [caplen=128][len=242][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=58] pfring_add_hash_filtering_rule(1) failed This error message indicates that pfring_add_hash_filtering_rule() returned failure in userland. Note that despite the returned error in userland, the hash rule has been added successfully in the kernel. Thanks, Amir On Mon, May 11, 2015 at 8:02 PM, Alfredo Cardigliano cardigli...@ntop.org mailto:cardigli...@ntop.org wrote: Hi Amir could you provide a sample application, or a code snippet, we can use to reproduce the issue? Thank you Alfredo On 11 May 2015, at 10:52, Amir Kaduri akadur...@gmail.com mailto:akadur...@gmail.com wrote: Hi, I'm experiencing a possible bug in the API pfring_handle_hash_filtering_rule(), when adding a rule. The API return -1 (failure) although the hash rule has been added successfully. I experience it in versions 6.0.2 and 6.0.3. In version 6.0.1 it works fine. Can anyone please confirm that there is a bug? If yes, can I have a patch for it, or even a quick-and-dirty explanation on how to solve it? 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
Re: [Ntop-misc] Possible bug in SW hash rule API
Hi Amir could you provide a sample application, or a code snippet, we can use to reproduce the issue? Thank you Alfredo On 11 May 2015, at 10:52, Amir Kaduri akadur...@gmail.com wrote: Hi, I'm experiencing a possible bug in the API pfring_handle_hash_filtering_rule(), when adding a rule. The API return -1 (failure) although the hash rule has been added successfully. I experience it in versions 6.0.2 and 6.0.3. In version 6.0.1 it works fine. Can anyone please confirm that there is a bug? If yes, can I have a patch for it, or even a quick-and-dirty explanation on how to solve it? 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
