Custom ip/port rules

[IvanNardi]

ndpi allow the users to define some custom rules via proto.txt" files. Among these rules, I am interested in talking about the ip/port rules (only).

There are 4 kind of these rules, at least:

• ip/port matching on custom (user defined) protocol

tcp:860,udp:860,tcp:3260,udp:3260@iSCSI
ip:213.75.179.11/32@CustomProtocol

• ip/port matching on existing protocol

tcp:81,tcp:8181@HTTP
ip:213.75.179.12/32@HTTP

How these rules should be handled, in theory? There are several possibilities:

1. these rules win over anything else, i.e. these rules are checked "first": first packet of the flow provides a complete and final classification.

2. these rules as used as fallback, only if "internal engine" doesn't found any classification (as suggested in #1322). In other words, these rules are checked "last".

3. Something else?

Current implementation (in ndpi_do_guess()) is a bit confused and these 4 cases are handled in quite different ways. I fear that these differences are historical, though.

How should we handle ip/port custom rules? @utoni , @lucaderi

[utoni]

2. these rules as used as fallback, only if "internal engine" doesn't found any classification (as suggested in [Custom Applications added into protos.txt file gets matched first, before the actual application detection happens #1322](https://github.com/ntop/nDPI/issues/1322)). In other words, these rules are checked "last".

I would prefer this solution, although it might be up to the user how much she trusts the correctness of the engine.

3. Something else?

What about a combination of 1. and 2. meaning that the user can specify in the protos.txt if it should matched before or after the engine tries to detect something?