Hi Alfredo, Shall I take the code from github ? Have you checked the point #2 also mentioned in my last email ?
Regards, Chandrika Sent from my iPhone On Nov 28, 2016, at 5:28 PM, Alfredo Cardigliano <[email protected]> wrote: Hi Chandrika 1. I reworked the hash to explicitly handle ip v4 vs v6 now, however the result should be the same as the non v4 portion in case of v4 should be 0’ed, thus not affecting the hash. 2. there is no need to comment the code, you just need to pass enable_frag_coherence=0 to pf_ring.ko (at insmod time, or using the configuration file if you are using packages) Alfredo On 23 Nov 2016, at 06:37, Chandrika Gautam <[email protected]> wrote: Hi Alfredo, While debugging this issue, I have found out two issues - 1. Below API using s6_addr32 which is an array of type uint32_t of size 4 and hence calculated hash gives a garbage value. I mentioned in my previous email that hash value getting generated are different and hash values are exceeding the Integer limit also Is there any specific reason to use s6_addr32 rather than using s6_addr. struct in6_addr { union { uint8_t __u6_addr8[16]; uint16_t __u6_addr16[8]; uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ }; #define s6_addr __u6_addr.__u6_addr8 #ifdef _KERNEL /* XXX nonstandard */ #define s6_addr8 __u6_addr.__u6_addr8 #define s6_addr16 __u6_addr.__u6_addr16 #define s6_addr32 __u6_addr.__u6_addr32 #endif static inline u_int32_t hash_pkt(u_int16_t vlan_id, u_int8_t proto, ip_addr host_peer_a, ip_addr host_peer_b, u_int16_t port_peer_a, u_int16_t port_peer_b) { return(vlan_id+proto+ host_peer_a.v6.s6_addr32[0]+host_peer_a.v6.s6_addr32[1]+ host_peer_a.v6.s6_addr32[2]+host_peer_a.v6.s6_addr32[3]+ host_peer_b.v6.s6_addr32[0]+host_peer_b.v6.s6_addr32[1]+ host_peer_b.v6.s6_addr32[2]+host_peer_b.v6.s6_addr32[3]+ port_peer_a+port_peer_b); } So I changed the above code to below and it started giving a value which make sense. I matched the hash value generated for few packets manually and it is matching. static inline u_int32_t hash_pkt(u_int16_t vlan_id, u_int8_t proto, ip_addr host_peer_a, ip_addr host_peer_b, u_int16_t port_peer_a, u_int16_t port_peer_b) { return(vlan_id+proto+ host_peer_a.v6.s6_addr[0]+host_peer_a.v6.s6_addr[1]+ host_peer_a.v6.s6_addr[2]+host_peer_a.v6.s6_addr[3]+ host_peer_b.v6.s6_addr[0]+host_peer_b.v6.s6_addr[1]+ host_peer_b.v6.s6_addr[2]+host_peer_b.v6.s6_addr[3]+ port_peer_a+port_peer_b); } 2. Clustering logic is not working as expected for out of order fragments. If non first fragment received first, then below snippet of code will enqueue this packet to an index 0 always. Existing code creates an entry in hash only when first fragment is received. I tried to modified this code to first search a fragment in hash and if not found, then insert in into the hash irrespective of the order of the fragment. But It did not work for some reason. Before even working on that piece of code, for our requirement of using cluster_2_tuple, I feel that we don't even require to use the cluster fragment hash at all since we need only source and destination IP address which will be present in each and every packet including fragments also. So I went ahead commenting whole piece of below code and just used "skb_hash = hash_pkt_cluster(cluster_ptr, &hdr);" to calculate the hash and it seems to work perfect. Even this will remove the overhead of using hashing. if (enable_frag_coherence && fragment_not_first) { if (skb_hash == -1) { /* read hash once */ skb_hash = get_fragment_app_id(hdr.extended_hdr.parsed_pkt.ipv4_src, hdr.extended_hdr.parsed_pkt.ipv4_dst, ip_id, more_fragments); if (skb_hash < 0) skb_hash = 0; } } else if (!(enable_frag_coherence && first_fragment) || skb_hash == -1) { /* compute hash once for all clusters in case of first fragment */ skb_hash = hash_pkt_cluster(cluster_ptr, &hdr); if (skb_hash < 0) skb_hash = -skb_hash; if (enable_frag_coherence && first_fragment) { add_fragment_app_id(hdr.extended_hdr.parsed_pkt.ipv4_src, hdr.extended_hdr.parsed_pkt.ipv4_dst, ip_id, skb_hash % num_cluster_elements); } } Do you foresee any issue if we go ahead with the mentioned above changes? Regards, Gautam On Thu, Nov 17, 2016 at 4:40 PM, Alfredo Cardigliano <[email protected]> wrote: > Hi Gautam > I will come back on this asap. > > Alfredo > > On 17 Nov 2016, at 07:47, Chandrika Gautam <[email protected]> > wrote: > > Hi Guys, > > Please help to resolve this. > > Regards, > Gautam > > > > _______________________________________________ > 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 _______________________________________________ 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
