-
Notifications
You must be signed in to change notification settings - Fork 910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect data in network protocol address lists. #2150
Comments
Hi @vel21ripn, thanks for these interesting inputs! Let' start with the real bug: the overlapping addresses... There are a few different cases:
|
We are loading the same AS list as GOTO See ntop#2150
We are loading the same AS list as GOTO See #2150
Another topic: aggregation. |
Thanks for the clarification regarding the MODBUS, iCloudPrivateRelay, ProtonVPN lists. Information on the benefits of address aggregation. |
@vel21ripn, could you check if bdb73db fixes the aggregation issue, please? |
Thank you. There is one more question: if the lists are generated by a script, then what is the point of storing ipv6 addresses as a string? |
Done in 5566439 |
No specific reasons: it was the simplest implementation...
You need to take into account at least one bytes for the prefix length: 2980 * (16 + 1) = 50660 > 50386. So, I don't think we have any space benefits from the binary format. |
Describe the bug
Some networks are described in more than one protocol.
Another problem is the lack of subnet aggregation.
To solve these problems, we need to abandon "include inc_generation/*.c.inc" and switch to automated construction of subnet lists.
It also makes sense to abandon separate loading of address lists. We need to make a mask of loaded lists and one list of addresses.
If I’m not mistaken, I proposed storing lists of addresses in .yaml files and collecting an optimized list of addresses from them, but for some reason the implementation was not included in nDPI. The format of the file with the list of addresses is not significant. Using '.c' files to store lists of addresses is also a good option.
The only difficulty in solving these problems is the lack of protocol names.
I use a non-cross-platform solution in the form of a perl script that generates the necessary data from the ndpi_protocol_ids.h file.
I don't know how much this is acceptable in an nDPI project.
I can offer my PR
Ambiguous address:
IPv4
IPv6
The text was updated successfully, but these errors were encountered: