Inconsistent byte order for parameters passed to ndpi_network_ptree_match

[bcronje]

As a follow up to issue #77 , currently there is inconsistent usage of the byte order of the in_addr *pin parameter of ndpi_network_ptree_match

Based on the existing implementation of ndpi_network_ptree_match it appears ndpi_network_ptree_match expects in_addr *pin to be in host byte order, as you convert to network byte order looking at your comment here:

pin->s_addr = ntohl(pin->s_addr); /* Make sure all in network byte order otherwise compares wont work */

I'm assuming ndpi_patricia_search_best expects the prefix to be in network byte order then. However the problem is currently it's a bit of a mess how ndpi_network_ptree_match is called:

ndpi_host_ptree_match - calls ndpi_network_ptree_match with pin in host byte order
tor_ptree_match - calls ndpi_network_ptree_match with pin in network byte order
ndpi_detection_process_packet - calls ndpi_network_ptree_match with pin in network byte order
ndpi_guess_undetected_protocol - calls ndpi_network_ptree_match with pin in host byte order

Also related:

ndpi_init_ptree_ipv4 fills the prefix in network byte order
ndpi_add_host_ip_subprotocol fills the prefix in host byte order

Shouldn't this all be normalized so that whenever a struct in_addr is used that it should already be in network byte order, as the documentation and convention of struct in_addr is documented as network byte order: http://man7.org/linux/man-pages/man7/ip.7.html ?

[bcronje]

@lucaderi do you guys want to tackle this internally? Or you happy if I take a shot at it?

[lucaderi]

Go ahead

[bcronje]

Great, should send through something later today.

[bcronje]

OK PR #84 send. You have already done a lot of the work in your previous commit, so this PR addressed the outstanding endianess issues I could pick up.

[lucaderi]

Thank you: all works as expected.